So I'm making a game for the PC.
Scythe
Join Date: 2002-01-25 Member: 46NS1 Playtester, Forum Moderators, Constellation, Reinforced - Silver
Join Date: 2002-01-25 Member: 46NS1 Playtester, Forum Moderators, Constellation, Reinforced - Silver
<div class="IPBDescription">Download available!</div>So an idea for a game struck me the other day and I thought I'd try my hand at programming for the DS. I've been dabbling in the sprite dealie-doos and I've got some rudimentary stuff working.
Lemmie give you all a rundown:
Isometric game view. 2D sprites. Think XCom:
<img src="http://www.tjhowse.com/usgfiles/xcom-screenie.gif" border="0" class="linked-image" />
Basic RPG elements. Skill trees. Character development choices. Force-esque abilities. Inventory, equipment slots. Real-time movement and combat. Pause button. Touchscreen for selecting loadout. Interplanetary travel on a ship. Might go so far as to procedurally generate play areas. That's blue-sky though. For now I've set my eyes on getting a basic engine working, walking around a map, swapping in sprites as needed and such.
I sat down for a good think about how the control is going to work in this game. Here's a a shot of a blank grid:
<img src="http://www.tjhowse.com/usgfiles/blankgrid.png" border="0" class="linked-image" />
And here's a textured one:
<img src="http://www.tjhowse.com/usgfiles/grid.png" border="0" class="linked-image" />
And here's one with some hand-drawn chaps on it to give a sense of perspective.
<img src="http://www.tjhowse.com/usgfiles/grid2.png" border="0" class="linked-image" />
I'm trying to figure out the best means of controlling the movement of the main character. Several methods have occurred to me:
1) D-pad up is up, left is left, right is right. Simplest, but the character is confined to diagonal squares, like a bishop in chess.
2) Up is northwest, right is northeast, down is southeast, right is southwest. All squares are accessible, but unintuitive.
3) Using the touchscreen to tap a square to move to. I want to avoid this if possible. I don't like the stylus obscuring parts of the screen and holding the DS with the stylus is awkward and it obscures the ABXY buttons.
4) GTA1 and 2 style. Left/right turns, up is forward, down is back. This'll probably be my preferred method, even if it is a tad unwieldy.
It had also occurred to me to go with a straight, vanishing-point view with horizontal lines parallel to the x axis of the screen, but that doesn't pay proper homage to Xcom. :�
I'd like to hear what everyone has to say on the subject of their preferred control method for this style of game.
--Scythe--
Lemmie give you all a rundown:
Isometric game view. 2D sprites. Think XCom:
<img src="http://www.tjhowse.com/usgfiles/xcom-screenie.gif" border="0" class="linked-image" />
Basic RPG elements. Skill trees. Character development choices. Force-esque abilities. Inventory, equipment slots. Real-time movement and combat. Pause button. Touchscreen for selecting loadout. Interplanetary travel on a ship. Might go so far as to procedurally generate play areas. That's blue-sky though. For now I've set my eyes on getting a basic engine working, walking around a map, swapping in sprites as needed and such.
I sat down for a good think about how the control is going to work in this game. Here's a a shot of a blank grid:
<img src="http://www.tjhowse.com/usgfiles/blankgrid.png" border="0" class="linked-image" />
And here's a textured one:
<img src="http://www.tjhowse.com/usgfiles/grid.png" border="0" class="linked-image" />
And here's one with some hand-drawn chaps on it to give a sense of perspective.
<img src="http://www.tjhowse.com/usgfiles/grid2.png" border="0" class="linked-image" />
I'm trying to figure out the best means of controlling the movement of the main character. Several methods have occurred to me:
1) D-pad up is up, left is left, right is right. Simplest, but the character is confined to diagonal squares, like a bishop in chess.
2) Up is northwest, right is northeast, down is southeast, right is southwest. All squares are accessible, but unintuitive.
3) Using the touchscreen to tap a square to move to. I want to avoid this if possible. I don't like the stylus obscuring parts of the screen and holding the DS with the stylus is awkward and it obscures the ABXY buttons.
4) GTA1 and 2 style. Left/right turns, up is forward, down is back. This'll probably be my preferred method, even if it is a tad unwieldy.
It had also occurred to me to go with a straight, vanishing-point view with horizontal lines parallel to the x axis of the screen, but that doesn't pay proper homage to Xcom. :�
I'd like to hear what everyone has to say on the subject of their preferred control method for this style of game.
--Scythe--
Comments
--Scythe--
<img src="http://xs116.xs.to/xs116/07234/move1.png" border="0" alt="IPB Image" />
Having up being right-up in the view seems to be a better way of doing it. Similar to #2 but rotated. Seems that having the dpad on the left twists your perspective a bit towards up-right to being forward.
--Scythe--
Having up being right-up in the view seems to be a better way of doing it. Similar to #2 but rotated. Seems that having the dpad on the left twists your perspective a bit towards up-right to being forward.
<!--QuoteEnd--></div><!--QuoteEEnd-->
I think I would prefer that for movement options the most.
Having up being right-up in the view seems to be a better way of doing it. Similar to #2 but rotated. Seems that having the dpad on the left twists your perspective a bit towards up-right to being forward.
<!--QuoteEnd--></div><!--QuoteEEnd-->
I think I would prefer that for movement options the most.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah I think you'll find that configuration is quite common amongst iso games.
Anyway, very cool to be attempting a console game, I've only ever managed small PC games. What language are you using?
<a href="http://wiki.gp2x.org/wiki/Main_Page" target="_blank">http://wiki.gp2x.org/wiki/Main_Page</a>
Different system, but the principles are the same.
So just out of curiosity, what are some of the differences for writing for a DS as opposed to another system, besides the hardware constraints. What languages and toolkits will you be using?
<!--QuoteEnd--></div><!--QuoteEEnd-->
The DS has a lot of nifty inbuilt support for 2D and 3D stuff. Specialised vram for storage and whatnot. I'm using the devkitPro and PAlib packages for the most part. They come with a bundle of tools for sprite conversion and compilation. Everything's in C++.
--Scythe--
#1 will probably be easiest for all gamers to use but personally I'm with you on #4. GTA/Zelda style is how I like these sorts of games.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Zelda didn't have controls to turn...
I'm with you Scythe; having to turn your character and give it RE-like controls would be disorienting for me anyway. I don't think the Bishop movement would be a logical answer either. The simple directions would do.
I assume you need the character to be fixed to squares, as in, the character can not end up at grid point 2, 4.3 or 2.2, 5.6, and instead must be at integer points.
How about if the movement were completely free, but once the player stops inputting data via the D-pad, the character moves to its nearest square? So the character moves kinda like he's attached to an elastic band, which is tied to the nearest square point; and only pulls him to his position when he is not being moved about.
Here's an idea...it might be a bit more complex than you are wanting to do, but we'll see.
I assume you need the character to be fixed to squares, as in, the character can not end up at grid point 2, 4.3 or 2.2, 5.6, and instead must be at integer points.
How about if the movement were completely free, but once the player stops inputting data via the D-pad, the character moves to its nearest square? So the character moves kinda like he's attached to an elastic band, which is tied to the nearest square point; and only pulls him to his position when he is not being moved about.
<!--QuoteEnd--></div><!--QuoteEEnd-->
That's silly. If you just wanted to move one square you'd have to find the right length of time it takes to make it no less than one square and no more than one square. You'd hit it really quickly at first then bounce back to where you started, then you'd hold it a little longer and bounce back, and you'd have to keep doing that until you found the sweet spot.
And god forbid you don't memorize that sweet spot perfectly becuase if you don't you'll have to do the trial and error thing again.
That's not even considering how weird it would be to constantly be snapping one place or another every time your character stopped moving.
That's silly. If you just wanted to move one square you'd have to find the right length of time it takes to make it no less than one square and no more than one square. You'd hit it really quickly at first then bounce back to where you started, then you'd hold it a little longer and bounce back, and you'd have to keep doing that until you found the sweet spot.
And god forbid you don't memorize that sweet spot perfectly becuase if you don't you'll have to do the trial and error thing again.
That's not even considering how weird it would be to constantly be snapping one place or another every time your character stopped moving. <!--QuoteEnd--></div><!--QuoteEEnd-->
You're silly.
OK you bring up some good points (which I was vaguely aware of when transmitting my idea), but they are all dependant on how the system is implemented, and how it looks on screen. So, in your vision of how it would work, it wouldn't work. In my vision of how it would work, it could work. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
But if the game requires precise movement (ie making concious choices about how many squares you want to move) then this isn't a good idea for it, unless it gave an indication of where the spaces are as you moved about.
In hindsight though, just drop the whole idea. It's easier for everybody.
I was wanting to get in on a sprite art game for awhile.
You're silly.
OK you bring up some good points (which I was vaguely aware of when transmitting my idea), but they are all dependant on how the system is implemented, and how it looks on screen. So, in your vision of how it would work, it wouldn't work. In my vision of how it would work, it could work. <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" />
But if the game requires precise movement (ie making concious choices about how many squares you want to move) then this isn't a good idea for it, unless it gave an indication of where the spaces are as you moved about.
In hindsight though, just drop the whole idea. It's easier for everybody.
<!--QuoteEnd--></div><!--QuoteEEnd-->
The solution would be to highlight the square you are currently "on"
I think that would actually work great for a TBS game, but would look really silly in anything real time. Then again, TBS on a DS really should just be using the touch screen.
That's an ingame screenshot! You may recognise the guy in the middle from xkcd.com. <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
I've got reading from the map array, assigning vram for sprite storage, loading sprites into registers, drawing the sprites across the screen and all that jazz. Next up is code for entity support. Entities will be both NPCs, other players (!!!), detail stuff (like 3d-ish pillars that'll fade out if you or an NPC is behind it), weapon effects and whatnot.
Still umming and arring about exactly what kind of game it'll be. I'm thinking of having star system network like master of orion. Once you're in a star system you'll see the planets around the sun. Once you're at a planet you'll be able to land on the surface of habitable planets or on floating gas mines on gaseous planets. I'm tossing up whether to have a 3d rotating view of the planet you're orbiting to pick a landing position. You'll only be able to land at structures. Once you land you'll be taken to the ground view for running around on foot.
As far as the broader game goes, I'm hoping to work towards something like the X series economy system, though highly simplified. Maybe 20 types of resource and 50 types of component making a couple hundred commodities. Anything mined or manufactured would go on a galactic matter network so I don't have to worry about trading ships or anything. The player will be able to buy/steal/build mines, factories and space stations.
Space combat just occurred to me. Hmm...
Got a bit ahead of myself there. This is all very far-fetched currently. Start small.
As far as player advancement goes I'm open to suggestions. I was thinking of having, at minimum, a talent tree kind of arrangement. In addition to that I'd like to see implants (Head, chest, arms, legs) and weapons. I want to steer clear of having armour and whatnot. Too WoW. :þ
As far as stats are concerned I'm not really enthused about the prospect at all. I'm not making a hardcore turn-based RPG. I think damage bonuses from weapons and other assorted bonuses from implants would be enough. I may go that way in the end. Not sure.
Implants are a thing I've liked in every game that's had them. Neocron, Syndicate, Eve, and Deus Ex. They reek of coolness. I'm thinking that the poo implants would give small bonuses to weapon accuracy and whatnot, mundane benefits, whereas the more exotic implants would give you skills from other parts of the talent tree that you precluded early on in your character development.
I'd also like to ask this community for a bit of help. I'm seeing myself needing a map editor for this game before long; editing the maps in ascii by hand is getting old. :þ If someone was to volunteer to write a basic win32 graphical interface that could produce the [255][255][8] char arrays that form a map, I'd be super-happy. It shouldn't be very difficult at all but the more I'm able to focus on the core of the game, the better.
--Scythe--
P.S. If you have a DS you really have no reason not to have a <a href="http://www.dslinker.com/" target="_blank">DSLinker</a>. They're cheap, they come in a 2 gigabyte variety, and they're dead easy to use. They are the king of DS homebrew solutions. Don't need to do any conversion, just drag'n'drop the .nds files onto the card over a USB link and away it goes.
I'd also like to ask this community for a bit of help. I'm seeing myself needing a map editor for this game before long; editing the maps in ascii by hand is getting old. :þ If someone was to volunteer to write a basic win32 graphical interface that could produce the [255][255][8] char arrays that form a map, I'd be super-happy. It shouldn't be very difficult at all but the more I'm able to focus on the core of the game, the better.
<!--QuoteEnd--></div><!--QuoteEEnd-->
I wrote a graphic map editor for a tile-based game engine I was working on like 2 years ago. It's a bit different to what you're after but could be modified without much trouble I think - it rocks OpenGL for graphics so I can't imagine it being hard to change the view...
You're welcome to the code if you want it but you'll need Delphi to work on it - I'm busy with some consulting work presently so I don't really have time to do anything with it myself
<!--sizeo:1--><span style="font-size:8pt;line-height:100%"><!--/sizeo-->in before you decide to make Deus Ex for the DS >.><!--sizec--></span><!--/sizec-->
^_^
I'd also like to ask this community for a bit of help. I'm seeing myself needing a map editor for this game before long; editing the maps in ascii by hand is getting old. :þ If someone was to volunteer to write a basic win32 graphical interface that could produce the [255][255][8] char arrays that form a map, I'd be super-happy. It shouldn't be very difficult at all but the more I'm able to focus on the core of the game, the better.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think a better option would be to store your map as a malloc'd array of structs rather than single chars.
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->typedef struct mapcell_s
{
int imageindex;
int... whatever etc.
} mapcell;
int width = 256;
int height = 256;
mapcell *map = (mapcell *)malloc(width * height * sizeof(mapcell));
mapcell cell = map[x + y * width];<!--c2--></div><!--ec2-->
Then do what you want with the cell. Since it's a struct, you can just add whatever info you need to the cell as you develop your app.
I know most of this must be pretty elementary to you if you have any experience with C++ (which I know you do). Another advantage of this is that you can have your map pretty much whatever size you want.
Just remember to free(map); afterwards <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
I hope I didn't screw any of that up; I haven't done C/C++ for like... 2 years <img src="style_emoticons/<#EMO_DIR#>/smile-fix.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile-fix.gif" />
--Scythe--
(and do you know if it will work with a slot 2 device instead of a slot 1?)
1. Everyone has similar tolerance (chosen at character creation). The stronger an implant is at any given level, the more tolerance it uses, and the less attractive it therefore makes the user to NPCs. IE, a level 1 implant that increases accuracy by a medium amount would use a lot of tolerance, but that same implant at level 10 would use much less. This is the "Scaling" solution.
2. The character gains tolerance as he levels up. Implants have no level or stat restrictions, but you are limited by your tolerance at any given level in order to equip implants. This means as you level you gain more toleranc,e which allows you to equip stronger implants, which makes you better. In this case, NPCs would have no reaction until your tolerance reached a certain fraction of maximum (say, 50%). After that they start reacting to the metal bits sticking out of you and become more negative. This is the "Static" solution.
So, when do we get to poke at this nifty little thing?
(and do you know if it will work with a slot 2 device instead of a slot 1?)
<!--QuoteEnd--></div><!--QuoteEEnd-->
You could play with it now... if by "play" you mean "walk around in a huge open space with a hideous blue border around everything.
I used to have a slot2 thing that took an SD card. Using this in combination with a passme should result in it working just fine.
As for Redford's idea: I really don't want to write a jillion lines of dialog for the game. Or put in anything more than a basic conversation system, if one at all. Think nethack.
I've just implemented a shiny new sprite memory allocator. It's hypersexy and uses a bare minimum of precious vram to store sprites. I am considering dropping back to 16 colour sprites, from 256 colour sprites, to save on vram. I'm not quite sure what effect this might have on how the game looks. Has anyone got any opinions on that front? I'd like to keep 256 colours if possible but the DS has only 128kB of sprite vram.
39 (Ground sprites on screen) * 64 * 32 (Dimensions of sprite) * 1B (256 colours) = 78kB of vram taken up with only the background sprites. <img src="style_emoticons/<#EMO_DIR#>/sad-fix.gif" style="vertical-align:middle" emoid=":(" border="0" alt="sad-fix.gif" /> That's not including the player sprite, NPC sprites or details like pillars or walls. I think 16 colours might be the way to go.
--Scythe--
--Scythe--