Hey,
I'm new to java development and I'm trying to write a game. I've made a map for the player to move around written in excel/notepad.
Pretty simple, everything's numbered 1-25,
e.g.
1111
1331
1111
would be building 3surrounded by a path.
Could anyone help me figure out how to get this into a java program so I can get a player to move around?
Much appreciated!!
So, basically, what you have so far are some numbers in a spreadsheet?
Well, it's a start I guess.
You'd need to implement a datastructure holding your gameworld, a way of presenting the current gameworld to the player and an animator that keeps the world alive (if you don't want turn-based, that is). Oh, and you need some way to capture the input from the player and parse that in the context of the gameworld so you can let the player interact with it.
Easy.
Sorry but I am new to this!!!
Ok like Tomas said, I pretty much have a spreadsheet of numbers. Which is supposed to be a map, the area the player can move around in.
What I want to do first is write a program so that the map appears on screen.
Does that make sense? Little less broad?
Vic
> Sorry but I am new to this!!!
>
> Ok like Tomas said, I pretty much have a spreadsheet
> of numbers. Which is supposed to be a map, the area
> the player can move around in.
>
> What I want to do first is write a program so that
> the map appears on screen.
> Does that make sense? Little less broad?
No, that was already implied.
There are a lot of ways you could do that.
How much do you know about Java?
About graphical techniques?
About data structures?
About computer science?
Not much, i've only just started programming.
It's a Final Year Project in college, supposed to be a challange that i've never used the program before.
So i'm just trying to learn now.
As for graphical techniques, data structures etc i'm allowed to use excel, paint(or something like it) and the sun, that's pretty much it.
I find it's often better to start with an overview of the game, and try to make that. It seems to me you're starting at the bottom here, with the representation of your world on disk.
Think about what kind of a game you want, what the player should be able to do and how the game should react. Try to write it down as a document, it doesn't have to be long or very well-written. A page, maybe two, is plenty. It's an idea to start writing it as if you've played the game and you're reviewing it for a magazine.
Once you've got a set idea about what you want the game to be you can break it down into components you'll need to present that game to the player.
- Do you need a world?
- Do you need to store what the player has done?
- Is there a goal?
- What are the actions available to the player?
- How will the player input into the game?
- Do you need to interpret the player's input in some composite way?
- How can you present the game-state to the player?
- When will you gather the input from the player?
- When will the game-state change?
- Do you need some special technology? (3D? Networking? J2ME?)
- What kinds of resources will the game need?
These are just some questions you should at least consider. Making a game isn't easy, but it sure is fun and rewarding....
I've been working on the overview for a couple months now, so I know what way I want to go, and what way i'm being told to go, it's just a matter of getting there.
I thought it would be easiest to start at the bottom and build in stages, so like the map first, the player second etc.
> - Do you need a world?
A world? Like a place for the player to move around in, yes.
> - Do you need to store what the player has done?
Yes, it's supposed to be a platform kind of game, so that the more you do/collect the further you can go in the game.
> - Is there a goal?
Yes to visit everywhere on the map
> - What are the actions available to the player?
simply movement, and entering text where asked
> - How will the player input into the game?
pop up questions, so the game pauses and gives/collects user info
> - Do you need to interpret the player's input in some
> composite way?
> - How can you present the game-state to the player?
What do you mean here? What will the player be able to see?
> - When will you gather the input from the player?
At the beginning and then at stages through the game
> - When will the game-state change?
as a goal is accomplished, the player may enter another building
> - Do you need some special technology? (3D?
> Networking? J2ME?)
The simpler the better, I have Sun to write programs in, but the hope is at the very end it will be played on a PDA.
> - What kinds of resources will the game need?
What do you mean by resources? Things seen in the game or what's needed to run it?
>
Well i'm hoping it's fun and rewarding, my final year of college depends on it!!!!
I have a feeling we're not communicating very well here. My list of questions weren't meant as a questionnaire that includes everything you need to know to make a game, more as talking-points and inspiration you might want to think about for your game.
Still - let me be a little more verbose
> - Do you need a world?
With this question I'm trying to get you thinking about what a game-world is. Some games need a game-world, others don't. A game-world is essentially some sort of datastructure containing a snapshot of your world at a particular time. It can be as simple as the current tic-tac-toe configuration or a huge and complex set of databases containing everything about a MMORPG. My point is: think about what state your game should store, and what that implies.
> - Do you need to store what the player has done?
Is the game-world changed by the player? Can it be revisited in the changed state, or is it once-off? If you need to store changes, what constraints will that put on the player's actions (don't want your world to be corrupted, do you?).
> - Is there a goal?
Exploration is a nice goal, but it caters to one particular kind of player. Some players like scores, maybe you could put that in there? Then explorers still get their fill, and achievers get theirs. Put the highscores online, and you have a meta-social layer to the whole thing. Etc, etc, ad nauseam. Having a goal influences how you design a game, and not having an explisit one may even encourage players to look for the goal.
> - What are the actions available to the player?
What are your game-mechanics (the things the player can do). Moving and entering text? How can the player move? Is it sideways or in four directions? Six? Eight? Free movement in 3D? Has the player got any attacks or will he be attacked? What does entering text do (answer questions? solve riddles? reflexive typing? social interactions?).
> - How will the player input into the game?
Is the player using the keyboard, a mouse, gamepad, combinations of the above? What possible combinations of input are there, and should these be customizable? What would be a good control-scheme for your chosen game-mechanics (e.g if you have movement do you want it to be mouse-controlled or keyboard)? Does the input have to come within certain limits (time, repetition, etc)?
> - Do you need to interpret the player's input in some
> composite way?
If you're having text, for example, should the text be parsed in some way? The computer doesn't understand English, so that might be prudent, unless it's as simple as typing in the correct word. Can combinations of keypresses mean something in your control-scheme? Can inputs mean different things at different times/stages in your game (eg. can up mean "move north" in one case and "ascend staircase" in another)?
> - How can you present the game-state to the player?
You as the developer have access to the game-world. It'll be some kind of data-structure. How will the player see it? Will you give him graphics or text? Will he be able to view everything at once, or will the perspective be restrained? Will you have status-indicators to tell the player about his relationship with the world?
> - When will you gather the input from the player?
Will the player be in control at all times? Will you poll the player's input, or will you interrupt your game-updates on input? When is it OK to ignore the player's input?
> - When will the game-state change?
Will you change the game-state whenever the player does something (is moving around a change in game-state, it might be if the player himself is part of the game-state)? Will changes be noticed by some special mechanisms (AI, script-hooks, GUI, etc)? Are there times when you will not accept changes to the game-state (like, before the player is instanced, or in special cases)?
> - Do you need some special technology? (3D?
> Networking? J2ME?)
If you plan to bring your game to a particular platform it's good to know this as early as possible. If you want your game to have sound, you'd better put hooks in there for it right from the start.
> - What kinds of resources will the game need?
I am talking about the resources on the computer the game runs on. Do you need a fast CPU, or large amounts of memory? Is a network-connection needed? Do you need certain files available (eg. sprites, sounds, libraries, maps, etc) for the game to run? Can any of the resources be absent and the game would still work? Do you need the resources during the entire life of the game (could you live with the network going down during game-play)?
As I said, these points are just meant to get you thinking about the game. Just let your mind run over them and try to fix the concept of the game in your mind as concretely as possible. And never forget that the game should be FUN!
Well, I think games should be fun.
