#170534 - kelpfoot - Thu Oct 01, 2009 4:34 am
I've got a simple 2D game here with realtime exploration and turn-based combat (it plays a bit like the original King's Bounty). I've even got the low-level graphics stuff sorted out (I've got a 2D compositor that can do smooth translations, which is enough for what I need). Problem is I have no sprites.
I have no graphics or sound effects at this point, so the game could theoretically have any kind of theme - fantasy, sci-fi, modern, whatever. I'll take anything at this point. I can't really move on to the next phase of game development until I have something I can actually play, and apparently I need sprites just to figure out what the hell is going on. (ASCII output isn't doing it for me, and I want to properly test my compositor.)
To get started I need sprites for several monsters, a player's avatar, and maybe some terrain types. I'd prefer some of the sprites to be animated, so I can get used to working with them.
If anyone can make specific suggestions, I'd be grateful. I might even post gameplay footage, whenever it's ready.
Technically this is for an iPhone game I intend to release on the App Store, so proper licensing is a plus. On the other hand, I probably won't use these sprites in the final product, so it's not a big deal if they're not 100% legitimate - I just want to get back to work on my game, and I guess I need sprites to do that.
I know this isn't an iPhone forum, but someone poe-nted me here. And anyway, I think we have common ground on this.
Last edited by kelpfoot on Mon Oct 05, 2009 8:44 pm; edited 1 time in total
#170536 - dantheman - Thu Oct 01, 2009 6:50 am
You could look into sprites created for the "RPG Maker" program. People made tons of sprite sheets for it, some original, some ripped from other games, and I imagine that there are still tons of them out there since the program was rather well-known several years ago.
#170544 - gauauu - Thu Oct 01, 2009 3:05 pm
Have you seen Reiner's tileset's? He's got a distinct visual style that you may or may not like, but he has tons of sprites and backgrounds that he gives away for free, with a very open license:
http://reinerstileset.4players.de/englisch.html
#170553 - kelpfoot - Thu Oct 01, 2009 8:05 pm
| gauauu wrote: |
Have you seen Reiner's tileset's? He's got a distinct visual style that you may or may not like, but he has tons of sprites and backgrounds that he gives away for free, with a very open license:
http://reinerstileset.4players.de/englisch.html |
They're isometric and they're not scifi, but hot damn, I'll take it.
I couldn't find the license. Is there a page where he describes it, or will I need to email him?
#170556 - gauauu - Thu Oct 01, 2009 10:06 pm
| kelpfoot wrote: |
They're isometric and they're not scifi, but hot damn, I'll take it. |
Some of the older tilesets aren't (or weren't, unless he got rid of them) isometric, but yeah, the majority are.
| Quote: |
| I couldn't find the license. Is there a page where he describes it, or will I need to email him? |
Right here http://reinerstileset.4players.de/readmeE.html#b
(under "Readable" in the left nav)
#170557 - kelpfoot - Thu Oct 01, 2009 10:34 pm
Argh, it looks like he ditched the non-isometric tilesets. Unfortunately the iPhone's display area isn't exactly huge, and it gets smaller when you start adding interface widgets to it; having a square grid that aligns with the edges of the screen makes a big difference in touchability.
Not that this will stop me from using his sprites, of course.
#170559 - kelpfoot - Thu Oct 01, 2009 11:28 pm
This is my first real crack at making a game, and it seems like you guys know what you're doing better than I do. Just to make sure I'm not going to run into any show-stopping problems, is it OK if I try to explain the game's basic architecture to all of you?
I know that almost all software projects ultimately fail (videogames very much included), so I'm trying to keep everything as brain-dead simple as possible. To that end the game basically has four parts:
- A "main" loop (not actually called main()) that basically runs forever and that is in charge of updating the game world. It interacts with the "interface" and "backend" components.
- A backend, which is mostly just a bunch of variables to keep track of the state of the game world. It contains an array to represent the world map, lists of all monsters/enemies that are roaming around, et cetera. Once per frame, the "not-main" loop will read from the backend, do some calculations (some of which are determined by user input), and then update the state of the backend. This is how "time" progresses in the game.
- A 2D compositor, that reads from the backend (once per frame, when it gets called at the end of each iteration of the not-main loop). It combines the values it reads from the backend with sprite data, and uses this information to draw each frame (painter's algorithm).
- An interface, which consists of components supplied almost entirely by Apple. It displays buttons and a view; the view contains the framebuffer drawn by the compositor, and the buttons correspond to variables that are accessed by the not-main loop.
I can provide more information (like headers) if that would be helpful.
I also need to figure out initialization, menus, transitions (like from exploration to combat), and save/loads. I have an inkling how to do all these things (eg save/loading the game by pausing the not-main loop, storing/overwriting the backend, and then resuming).
In spite of all of this, and also in spite of the fact that I've written quite a bit of code already, I still feel completely overwhelmed. I'd be relieved in someone more experienced than myself could point out where I'm about to fuck up. Advice welcome.
#170561 - gauauu - Fri Oct 02, 2009 1:26 am
The overall architecture sounds pretty reasonable.
Really, the best way to learn it is to do it. Over and over again. You will mess things up, and wish you had done it differently. That's how you learn. My biggest suggestion is to smart small, and build up incrementally. If you plan for a huge RPG project for your first game, you are setting yourself up for utter failure. But if you start relatively small, you'll learn a lot as you go.
#170562 - kelpfoot - Fri Oct 02, 2009 2:06 am
What about the compositor? It's just some bullshit I wrote myself; it doesn't even use OpenGL or anything. (I looked around for some open source libraries, but none were stable/well-documented/available under a good license, as far as I could tell.) Was that a huge mistake?
I've got a 300 * 300 display area for the framebuffer, I need at least four rendering layers, and I want at least 30fps; given my slightly brain-damaged algorithm (which processes transparent pixels), that's 10,800,000 pixels/second. Do you think this will work out for me, or am I going to pull some hair out optimizing this bitch? (I haven't done any performance testing, yet; I'm still working on how to import those sprites.)
Apologies for the barrage of questions. I'm having trouble mustering the will to get back to writing code.
#170564 - kelpfoot - Fri Oct 02, 2009 5:39 am
OK, I'm clearly overthinking this. I've rewritten the game from scratch twice already, it's not like it would be a big deal if I had to do it one more time.
Anyway, working with sprites is a pain in the ass. I'm going to give Cocos2D another look.
#170588 - kelpfoot - Sun Oct 04, 2009 7:22 pm
Is it OK if I use this thread as a development log, even though I'm technically working on an iPhone game? Because I have both progress and non-progress to report.
I also have the world's most uninteresting screenshots.
#170594 - kelpfoot - Mon Oct 05, 2009 8:43 pm
DONE:
World map
Player movement (exploration mode)
Menu transitions
Combat transitions
Loading resources from external files
TODO:
Gamesaves
Graphics/Cocos2D integration
Animation/timing
Sound
Combat mechanics
World map is unpopulated
Random map generation?
TODO AFTER THAT:
Gameplay balancing
Storywriting (as though I give a damn)
All the other stuff I forgot.
I'll be busy until next weekend or so, so don't expect much in the way of updates until then. (Clearly you're all just waiting with bated breath.)
#170595 - gauauu - Mon Oct 05, 2009 8:59 pm
| kelpfoot wrote: |
| Is it OK if I use this thread as a development log, even though I'm technically working on an iPhone game? Because I have both progress and non-progress to report. |
Well, beginners is somewhat the wrong forum for it, but I don't think people will mind now that the thread is created. Although I'd recommend more descriptive textual posts than the last. Or add some screenshots, or more info about your game, or something along those lines, to try to grab our interest ;-)
#170610 - kelpfoot - Tue Oct 06, 2009 10:30 pm
If you want to know the basic gameplay mechanics, I suggest you watch some YouTube videos of the original King's Bounty. My game will hopefully play a bit like that, when I'm finished.
Did I mention that my screenshots were uninteresting? Because they are.
[Images not permitted - Click here to view it]
What you're seeing is an example of "exploration mode," where the player wanders around freely on the world map. Underscores indicate navigable terrain, 'M' indicates everything else. (There will eventually be other kinds of terrain, like forests, mountains, et cetera.) The seven by seven character grid is an ASCII representation of the game map. (I could obviously make the grid bigger, and I should probably be using a fixed-width font, but then again, there's still all sorts of little shit I haven't done yet.) 'P' indicates the player's current position. The directional buttons cause the player to move one square in the appropriate direction, assuming this is possible. They also cause the game to advance by one unit of time (exploration isn't realtime yet).
The green thing is a framebuffer I'm not actually using at this point. Helpfully, it can receive touch events and bind them to actions, which will be useful later on, but it doesn't do me any good just yet.
The Menu button works, but only insofar as it pauses the game and changes the display output - but otherwise it doesn't actually do anything.
Combat is similar to the menus, in that I have hooks to handle it, but it's not really implemented yet. I'll also need to add more UI buttons, obviously. (Small refinement over King's Bounty: It will hopefully be possible for players to select units on screen by tapping them instead of using the D-pad.)
The UI is ugly as sin at this point, but I can easily fix that later on, when I find appropriate tooltips or whatever. Interface builder is unbelievably easy.
My main priorities at this point are 1) to add transitions to exploration mode, so players can visit towns/collect loot/fight roaming monsters; 2) to populate the world map with towns/loot/roaming monsters; 3) to learn Cocos2D so I can integrate my project with it. I probably won't have time for any of these things until this weekend.
#170613 - kelpfoot - Wed Oct 07, 2009 4:04 am
Oh, that tiny boxed-in world map is mostly just for testing. The window is scrollable (centered on the hero); new maps can be loaded from text files, with sizes (currently, arbitrarily) up to 1024 * 1024. The format goes like this:
4 4 m m m m m _ _ m m _ 1 _ m m m m m
The first two numbers mean that this is a 4 square by 4 square map. The 'm' indicates what I assume will eventually be a mountain. Underscores are passable terrain, and the 1 indicates that the square preceding it contains the object whose reference number is 1 (that would be the hero). It would render like this:
M M M M
M _ _ M
M p _ M
M M M M
With p indicating the player's square.
(When I have graphics set up, I plan to let the player move distances shorter than one square, so that the animation is smooth; but as far as the game engine is concerned, the player will probably still be occupying the area of an entire square.)
#170623 - kelpfoot - Wed Oct 07, 2009 8:28 pm
Have I stunned everyone into silence with my horrible UI?
#170624 - gauauu - Wed Oct 07, 2009 10:50 pm
No, you just haven't done much to make us care about the project. I don't mean that as an offense, but we probably won't interested until you've actually gotten the project somewhere.
And then only marginally interested because it has nothing to do with GBA or DS.
#170625 - kelpfoot - Wed Oct 07, 2009 11:25 pm
Fair enough. This thread really only exists because someone on another forum was asking me about iPhone development, and also because I needed to find sprites.
The guy who was asking seems to have disappeared, and you helped me find sprites (thanks for that), so I guess I might as well slink off to another forum.
I'm still working, by the way, and if you can get around that terrible UI, there actually is the beginning of a game under there.
#170629 - gauauu - Thu Oct 08, 2009 2:58 pm
Sounds reasonable. But I hope I didn't come across as rude, because we DO like to help reasonable people in development, no matter what platform. I'd recommend coming back and posting your progress here when you've made some significant milestones.
Good luck with the project!
#170680 - kelpfoot - Sun Oct 11, 2009 9:47 pm
| gauauu wrote: |
| I'd recommend coming back and posting your progress here when you've made some significant milestones. |
Well, it turns out that (because of how the App Store works) I'll either need to pay a lot of money to incorporate or I'll have to release the app under my real name, and unfortunately the name "kelpfoot" is also associated with an occasionally douchey forum that is best kept far from my personal life. For my privacy, I'm probably not going to discuss any personal projects from now on.
Actually, there's one more thing I'll say. Even though I've hammered out all the logic/backend stuff, to the point where literally all I need to do is send information to a compositor function and wait for it to return a rendered frame, I'm having quite a challenge getting to the next step.
The idea of having to actually load hundreds of images into a program and then manage them seems daunting, to say the least. Furthermore, I can't really think of any elegant way to do it. I could just load the binary pixel data straight into the compositor I already wrote, and this would be the easiest thing, but I'd still have to do a lot of hand-tuning for each individual sprite and animation loop, and the end result would be difficult to modify later on. I could write an interface to load sprites from an external file, but first I'd need to think of a way to do that, and then I'd need to actually write and test a fair bit of code - and I'm not 100% sure that this will give me any practical advantage over the easier method.
Lastly I can integrate my game with an existing project, like Cocos2D, but this is probably the most difficult of all, and once again I'm not actually sure what practical advantages it will bring me in terms of getting work done.
I guess I actually do have one last question: Is there an easy method of dealing with sprites and I've overlooked it, or is this something where you have to just sit down and slog through it the hard, obvious way?
#170690 - gauauu - Mon Oct 12, 2009 4:06 pm
| kelpfoot wrote: |
I guess I actually do have one last question: Is there an easy method of dealing with sprites and I've overlooked it, or is this something where you have to just sit down and slog through it the hard, obvious way? |
I'm not sure exactly what you're asking, but each sprite should have both an image, and a set of information that tell properties about it, such as animation frames, timing, etc. They should get loaded together at the same time, so that the display code just processes the properties and displays the image for the sprite appropriately.
Does that answer your question, or am I talking about something completely different?
#170708 - kelpfoot - Wed Oct 14, 2009 1:29 am
You're on the right page, but that's not quite what I was trying to ask.
I'm looking at the source code for Cocos2D, to see how they solve this problem. Apparently they implement an interface for something called the "Atlas Sprite Sheet," which looks... arcane.
Anyway, I'll figure it out.
#170723 - sgeos - Thu Oct 15, 2009 12:49 am
Each critter in your game should have a bunch of properties, one of them being display. It does not matter how all of this information is organized, but all of these properties will need to be stored somewhere. Also, some sort of art spec should put you a few steps in the direction of being properly organized.
Here is an example that incorporates reuse. All of this would probably be stored in XML files, with the meaning of each property defined is some sort of spec. "Phantom Hound" has a custom walk animation that uses the standard dog graphics page.
Unit: Black Cat
Graphic Page: Cat
Palette: Black Animal
Walk Animation: Standard Walk
Hit Detection: Land Animal
Unit: Black Dog
Graphic Page: Dog
Palette: Black Animal
Walk Animation: Standard Walk
Hit Detection: Land Animal
Unit: Phantom Hound
Graphic Page: Dog
Palette: Ghost
Walk Animation: Phantom Hound
Hit Detection: Ghost
![[Images not permitted - Click here to view it]](http://img19.imageshack.us/img19/3899/snap1rt.jpg){kind=link}