Closed Thread
Why does it have to be simple procedural or complex object oriented? I think that starting with simple object oriented would teach you more since you will probably use OOP for more complex games.
Also, you say every java game programming book is too specific. You might have more luck finding a book that teaches game programming concepts if you don't use a language specific book. For example Code Complete teaches good practices while not being linked to any particular language. I don't really know a game programming equivalent, but if you look at some of the articles on this site you can learn about isometric tiles and other subjects.
Also, you say every java game programming book is too specific. You might have more luck finding a book that teaches game programming concepts if you don't use a language specific book. For example Code Complete teaches good practices while not being linked to any particular language. I don't really know a game programming equivalent, but if you look at some of the articles on this site you can learn about isometric tiles and other subjects.
I don't really have any good tutorials or anything for you, except a while ago I was trying to create my own level editor and ended up creating a little thing which allowed me to read / write from a text file
It only really applies to tile based maps, but it is pretty simple to read / write levels in a text document. The way I created the levels was by simply going into the text document and adding more "b"s or "i"s to place blocks. More recently I tried creating a game which I had a level editor and I placed objects in the levels which were written into a text file with all attributes which could be read with a text parser. It seemed like it would work correctly (I never found out an error which prevented it from running).
Personally I've found GUIs to be really hard to build so you might want to stay away from them if you could help it. Or if anybody has a good way to create GUIs that would help you and me
+Good luck on future projects!
public Level(int levelXInBlocks, int levelYInBlocks, int levelNumber){
levelComposition = new Block[levelXInBlocks][levelYInBlocks];
System.out.println(levelComposition);
levelX = levelXInBlocks;
levelY = levelYInBlocks;
this.levelNumber = levelNumber;
setLevel(levelNumber);
}
public void setLevel(int levelNumber){
String[] eachLine = new String[128];
try{
FileReader fr = new FileReader("level" + levelNumber + ".txt");
BufferedReader br = new BufferedReader(fr);
String record = new String();
int lineOn = 0;
System.out.println("Loading level " + levelNumber);
while((record = br.readLine()) != null){
eachLine[lineOn] = record;
lineOn += 1;
}
} catch(IOException e){
System.out.println("No file found 
");
}
generateBlocks(eachLine);
}
/*
o = air = 0
b = brick = 1
i = ice = 2
*/
public void generateBlocks(String[] levelNotation){
for(int i = 0; i < levelY; i ++){
System.out.println(levelNotation);
String tempS = levelNotation.toLowerCase();
char[] c = tempS.toCharArray();
for(int blockCounter = 0; blockCounter < c.length; blockCounter++){
char tempC = c[blockCounter];
if(tempC == 'o'){
levelComposition[blockCounter] = new Block(0);
} else if(tempC == 'b'){
levelComposition[blockCounter] = new Block(1);
} else if(tempC == 'p'){
levelComposition[blockCounter] = new Block(0);
p = new Player((blockCounter * 25),(i*25));
} else if(tempC == 'i'){
levelComposition[blockCounter] = new Block(2);
} else if(tempC == 'f'){
levelComposition[blockCounter] = new Block(3);
} else if(tempC == '<'){
levelComposition[blockCounter] = new Block(4);
}
}
}
}It only really applies to tile based maps, but it is pretty simple to read / write levels in a text document. The way I created the levels was by simply going into the text document and adding more "b"s or "i"s to place blocks. More recently I tried creating a game which I had a level editor and I placed objects in the levels which were written into a text file with all attributes which could be read with a text parser. It seemed like it would work correctly (I never found out an error which prevented it from running).
Personally I've found GUIs to be really hard to build so you might want to stay away from them if you could help it. Or if anybody has a good way to create GUIs that would help you and me
+Good luck on future projects!
Well, you should start at the very beginning of such a Programm. The Interface. Look for Java APIS which are helping you to create Windows in Windows and/or Mac..
Than create some Windows, write Code to load pictures, write Code to pick Pictures, write Code to draw a map, write Code to draw different Layers, write Code....
A lot of working in front of you :-) But first, u should start with the Interface.. so google .. i bet Java has some cool Apis for Windows drawing..
peace
Than create some Windows, write Code to load pictures, write Code to pick Pictures, write Code to draw a map, write Code to draw different Layers, write Code....
A lot of working in front of you :-) But first, u should start with the Interface.. so google .. i bet Java has some cool Apis for Windows drawing..
peace
I don't care how experienced you are, if you have to ask this question, you're not ready for the task. Start small, don't try to make the whole editor at once.
As has already been suggested, look into programming an interface. Though like I said, don't try to make the interface for the editor. Just make an interface that works. something like, click on file and it makes a button pop up. Then clicking that button makes it disappear. Or make something simple that can read a text file, and then render the text that is in the text file.
You may have done twenty of those tuts, but it sounds to me like you just copy pasted your way through them. The basic tutorials should be teaching you how to think like a programmer, how to understand how your code will flow when it runs. Ask your brothers how long it took them to be able to code a game bigger than a side scroller or arkanoid on their own... I'm sure they'll say a couple years. Another thing to learn is not to get to far ahead of your self. Step back and think about the baby steps that it will take to make your program. You can't just say I want to make a million dollars if you don't know the steps that will get you there.
No offense, but alot of what you're asking about is basic stuff, but I've been programming for 13-14 years. Keep at the smaller games, try making a tetris clone that works off a tile map. Just what ever you do, don't give up.
As has already been suggested, look into programming an interface. Though like I said, don't try to make the interface for the editor. Just make an interface that works. something like, click on file and it makes a button pop up. Then clicking that button makes it disappear. Or make something simple that can read a text file, and then render the text that is in the text file.
Or really, ANY 2D game development book, tutorial, etc. that goes beyond these repetitive cookie-cutter "Breakout" tutorials. Yes, I have already done about 20 of these, from snake to breakout, and they're all rudimentary tutorials about basics I already know. They do not help me build more complex games, such as a series of images I can place in the world to form a map, so I can have my character walk around in something other than emptiness. None go into A.I. more than a very, very simple amount. None go into tile-based movement or A.I. pathfinding, how to create radial pie menus, or anything beyond the very basic of basics.
You may have done twenty of those tuts, but it sounds to me like you just copy pasted your way through them. The basic tutorials should be teaching you how to think like a programmer, how to understand how your code will flow when it runs. Ask your brothers how long it took them to be able to code a game bigger than a side scroller or arkanoid on their own... I'm sure they'll say a couple years. Another thing to learn is not to get to far ahead of your self. Step back and think about the baby steps that it will take to make your program. You can't just say I want to make a million dollars if you don't know the steps that will get you there.
No offense, but alot of what you're asking about is basic stuff, but I've been programming for 13-14 years. Keep at the smaller games, try making a tetris clone that works off a tile map. Just what ever you do, don't give up.
I'm not sure why you were so aggressive towards me, just because I am asking for help with the basics of "Where to start?"
because you clearly state that you know what you're doing, but still ask how to start.
I am not very experienced with making actual programs, but I am intermediately experienced understanding the code.
[/quote]
Then you back track. It's great that you understand code, but if you don't know how to use it, you still need to learn. That's what the simple programs are great for, they teach you how to put programs together. If you wrote these twenty plus games like you say, you should have a grasp on how to put a tile map together.
Should I begin with a World Editor? Basic GUI? An image based array? Code based significantly off of TILED? etc. etc.
These are legitimate questions, and I am certainly ready for the task.
[/quote]
Those are all so random, but since you already have ideas of were to start, why not just pick one yourself and get started.
I am not sure why asking "Where should I start, and what smaller step should I consider first during the very first step?"
[/quote]
If you're not sure why you're asking, you might have bigger problems than you think.
Coming from someone who's been programming for 13-14 years, this is quite disappointing of a non-answer. If I wanted to be told "You can't do it!" by a pro, I'd go to less professional forums.
[/quote]
Never said I was a pro, just wanted to make it clear that you'll learn more and more over time, and not to try to do everything at once. Nor did I say you can't do it, rather that you're probably not ready for such a big project.
What you should probably consider is that you've been programming for 13-14 years. Not only do you not fully know what it's like to be a newbie with the advancement of technology, you probably didn't even start your newbie experience with something as advanced as Slick2D. Lecturing others who have already made these stupid arcade games over 20 times, to make more arcade games, is like trying to tell someone who has mastered the ability to draw stick figures, to continue to draw stick figures because they "obviously don't know how to draw real figures."
[/quote]
I actually started programming in QB, around the time the industry was moving away from DOS and more into pure windows, and ASM for a ti-83 calculator. And in my art, all my characters start off as stick figures or worse. Just like with programming you can't just slap together a finished game without first putting together the building blocks.
This is a very interesting topic, because I think every creative individual goes through the same process: how to turn a concept or idea into implementable detail.
Sometimes just the idea can be very daunting, so I guess each individual has to find their own way.
Game programming is not just technical skill but also an art. You have to be able to visualize what you want to achieve and this takes a level of creativity that not all people can achieve. So naturally, even if you acquire technical skill, you will still have the "where do I go from here?" query.
So some of my suggestions would be to, from a purely hobbyist point of view:
First approach:
1. Put your ideas down on pen and paper. Start by naming your genre. Start by going through a few games in that genre and ask what different you can do. Try to draw a rough sketch of the game, or if you don't want to do that, just note your ideas in a pad. Try to figure out a plan.
2. Now start with implementing your idea by breaking it down into chunks: I want to do this: so I will begin with this and that and go on to the next.
3. Try to get a working model of your idea on actual program code. Forget the graphics first. If you cannot get by without graphics, try to create placeholders for your graphics, like basic shapes.
4. Now work your way into the logic of the game. How should the game respond to user input? That is usually a good place to start, because user input will be the main driving force of your coding. From user input will flow all other game interactions and implementation details
5. To break the monotony of coding, try to indugle yourself in other creative pursuits, like drawing or writing if you are so inclined.
6. Don't be overambitious but don't be too modest in your goals either.
7. Try to learn something new as you go along. Doing repetitive tasks can get boring.
Second approach:
Just start coding. And see where you go from there. Sometimes you might find yourself on a good thing just by experimenting.
By the way, there was a book I read in my Youth called "Action adventure arcade" or something. It was about 2d game programming in DOS with the use of a graphics library called FASTGRAPH. There was a lot of useful info in that book about tile-based scrolling and creating side scrolling games, with full example code and artwork. Not sure if that book is still in print.
Sometimes just the idea can be very daunting, so I guess each individual has to find their own way.
Game programming is not just technical skill but also an art. You have to be able to visualize what you want to achieve and this takes a level of creativity that not all people can achieve. So naturally, even if you acquire technical skill, you will still have the "where do I go from here?" query.
So some of my suggestions would be to, from a purely hobbyist point of view:
First approach:
1. Put your ideas down on pen and paper. Start by naming your genre. Start by going through a few games in that genre and ask what different you can do. Try to draw a rough sketch of the game, or if you don't want to do that, just note your ideas in a pad. Try to figure out a plan.
2. Now start with implementing your idea by breaking it down into chunks: I want to do this: so I will begin with this and that and go on to the next.
3. Try to get a working model of your idea on actual program code. Forget the graphics first. If you cannot get by without graphics, try to create placeholders for your graphics, like basic shapes.
4. Now work your way into the logic of the game. How should the game respond to user input? That is usually a good place to start, because user input will be the main driving force of your coding. From user input will flow all other game interactions and implementation details
5. To break the monotony of coding, try to indugle yourself in other creative pursuits, like drawing or writing if you are so inclined.
6. Don't be overambitious but don't be too modest in your goals either.
7. Try to learn something new as you go along. Doing repetitive tasks can get boring.
Second approach:
Just start coding. And see where you go from there. Sometimes you might find yourself on a good thing just by experimenting.
By the way, there was a book I read in my Youth called "Action adventure arcade" or something. It was about 2d game programming in DOS with the use of a graphics library called FASTGRAPH. There was a lot of useful info in that book about tile-based scrolling and creating side scrolling games, with full example code and artwork. Not sure if that book is still in print.
Really, I'd just love to figure out a simple system such as, a menu which I can click, take me to a new window to select an image, and then back to the world to place the image (it being visible, but not placed yet, like a RTS game) and then clicking to place it in a "world" which I can save to file.
This is relatively straightforward, where are you running into difficulty?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
