• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

327 Neutral

About cbreiny

  • Rank

Personal Information

  1. I would do C# with XNA, or Python with Pygame. I like the Python route personally if you're just getting started. It's really really easy to learn and it is also cross-platform. If you're new to game development, or even programming in general, then you really need to focus on learning the fundamentals of programming as well as the fundamentals of basic 2D game development. Learning the basics of C# is going to be easier than trying to learn C++ for more people, but Python is going to be easier to both as it's the language closest to English.
  2. being realistic

    If you want to make a really nice looking game in using SDL or OpenGL, then yes, even if it's just you, it is possible. The problem is, if this is your first game and you plan to make a kickass MMORPG with stunning 2D graphics, you simply aren't going to be able to do it. You need to start out small. It's really as simple as that. 99% of game indie game developers are not going to produce a big title that generates large amounts of revenue, for their FIRST game. Even if your goal isn't to generate revenue, writing a full-scale, beautiful, stunning 2D game, MOST LIKELY won't be realistic for you if you're just starting out. I really would start small, tower defense games, pac-man clones, pong-like games, etc. are all great places to start. And you need to get more than just the basics of what you need all down before you try to develop the full-scale 2D game of your dreams. That being said, ALL of the really nice and successful 2D games out there are successful because of great game ideas, great game physics, collision detect, etc, AND stunning art. If you are not confident in doing all of that yourself, what you're asking most likely won't happen.
  3. Help, teaching 12-13 year olds to code

    I thought a 6 month programming and game dev class to a few kids all in that same age group. I used Python though, since it's the language that is closest to English and is assumed the easiest language to learn. It was a pretty fun class, by the end of it each student had made there own (simple) 2D game in Python using the Pygame library. I also covered some basics of pixel art for a 8-bit art style, so that on the days they didn't feel like programming, they could work on the artwork for their game. They liked that because every bit of code and art was all theirs, so the each game was completely unique. I spent the first 2 months teaching them Python. I found that this was the most boring part of the class to them since you weren't doing anything visual. So in attempt to make the class more fun, we made a lot of text adventures. Started off mostly with just a bunch of if/else statements, then added in some more complex stuff, and I thought them some basic OOP. After teaching them Python for a couple months, I felt I was loosing their interest a little bit (they are 12-13 years old and typing isn't the funnest thing to them). So we steered a little bit away from programming and I thought them a lot about pixel art and game design. Which got them absolutely pumped to make their own game. They immediately started planning their games and working on the art. I was pretty clear on them being as fun and creative as they wanted, but also gave them a decent understanding of what was actually possible in the time-frame we had. We did a 'Design' phase of the class where we just planned and drew a lot of pixel art for just under a month. We then spent the last 3 months just working on our games every class day. I only taught the class Monday-Wednesday-Friday, which is probably why they didn't get bored of doing the same thing each day. I made sure to HELP them answer any questions they had. I didn't just give them all the answers on how to do everything, but helped them teach themselves. There was a lot of collaboration too. The first half of class was spent as a class talking about new concepts they wanted to add to their games (collision detection, tiled maps, etc), then I would teach them one or two ways to do what they wanted, explaining the 'hows' and 'whys' in ways that made sense to them. Then the second half of the class I just walked around the class room talking to each student as an individual, and helped them by answering any questions and giving them ideas on how to implement their own ideas. There where definitely days when none of them wanted to work, so on those days I would go to YouTube and we'd find some game dev videos by other people showing off what they have done and their idea, this was great because it sort of 're-motivated' the kids and sparked some new ideas. I also showed them a lot of completely finished and polished 2D games to give them some more inspiration and ideas and let them play these games (if they wanted, which most of them did) for the last 30 minutes of each Friday class. It was definitely a fun class to teach even though it had a few difficult days, but the kids loved it. They all finished their own 2D game by the end of the class, some better than others, but all of them totally unique. One kid made a platformer, and another made a pac-man clone (with much more basic AI), and the others had games in between. Some things the kids really liked about the class: -They got to make their very own game, no rules (within school policies), no limits. Each game was completely custom and all of them where different. -They drew all of their own art for the game. Which just made it that much more unique. -I didn't have any 'tests' or 'quizzes', I just gave them a pass or fail grade depending on if they where actually working and trying to complete the class (all of them passed). -The last 30 minutes of each Friday class was 'game time', where I let them play some 2D games (kept it 2D to keep it relevant to the class). -How I HELPED them solve their problems, instead of just give them all the answers. -They really liked that for the second half of the class, they worked on their own stuff instead of me lecturing the whole time. -I never actually gave them a 'lecture', it was always more of a discussion. I found that going to rants about say, tiled maps, just confused and bored them to death. So I discussed with them things they wanted to implement and ideas on how to implement them, with the exception of the basics (such as collision detection, movement, etc). Some things they didn't like: -Some days they didn't feel like programming at all. I found that having them work on art instead on those days helped a lot. But there where some days they didn't want to do art either, that's when I pulled at the game dev videos on Youtube of other people projects, and I showed them a lot of my projects too. This kept them motivated and interested. -For the first few months when I was teaching them Python, there wasn't anything visual, text adventures where the best thing I could think of, but they are 12-13. Words can only be so interesting to them. Just make sure you have a few pizza and game parties. That really helped them to have more fun and it made them like me as a teacher a lot more. I had a small class of only 6 students, so that made the 1 on 1 time with them possible, if your class is much bigger than that, you probably won't be able to do that. Or you won't be able to talk to each one every day. But I really think the 1 on 1 time really helped them open up and get their own personal ideas into the game. I found that when I was more talking to the whole class, all of their games where looking similar, but when you talk with each one, you help them to add their own ideas to it. Just some advice anyway. I really enjoyed teaching the class, and for the most part, so did all of the kids. For that age group, I definitely recommend using Python/Pygame though.
  4. what to start with?

    I would definitely recommend learning Python using the library Pygame for making 2D games. It's a great place to start and really easy to learn with how much documentation there is lying around. [url="http://www.pygame.org/"]Pygame.org[/url] is loaded with documentation!
  5. What library should I start with?

    I wouldn't try to learn a whole new language at the same time you're taking classes on C++, you might end up confused and start mixing them up a little. If you really do have a good basic understanding of C++ and would like to start game development, look into the SDL and SFML libraries. Both are great starting points and are really easy to learn. I've done a decent amount with both libraries and would personally recommend going with SDL simply because I feel like there is more documentation around on the internet, making it slightly easier to learn. A full-scale 2D RPG like Final Fantasy is definitely a big task to take on for your very first game development project! I'm not sure where your motivation level is on working on this project, but lot's of beginners that start out with big projects like this end up frustrated and/or stuck a month or two into development, and usually give up on the project. That being said, I would start off with some really small, simple projects to get a firm grasp of knowledge for whatever library you choose. Start with getting an image on a screen and get down basic movements with the arrow keys. Maybe give the image some animations. Then work on a collision detection program, followed by a basic tiled map engine that uses your collision detection. Work on some image rotation and maybe loading/saving game states. I know it's not quite as fun, but it's definitely worth it to have all of these small projects lying around when it's time to work on a big project like a 2D RPG. You want to be prepared before taking on such a project! After you get down all those basics listed above, start moving on to some more complex stuff like some basic Artificial Intelligence (A* is a good algorithm to start with), adding a 'scrolling' feature to your map engine, random map generation (could be used for caves/dungeons for games), etc.. Then start throwing all this stuff together in some smaller games. Tower defense games, Pac-Man clones, Pong-like games, etc. are all some great places to start! Once you've spent a lot of time researching and learning all these things, AND you feel confident, then you can start working throwing a prototype of a basic 2D RPG, then slowly make it more and more awesome. Just remember, these things take a lot of time, ESPECIALLY if you are going to do all the art yourself too. Anyways, I'm not trying to kill your dreams of making a badass 2D RPG like Final Fantasy, just letting you know that it's much easier in the long run if you work up to it! [url="http://lazyfoo.net/SDL_tutorials/index.php"]Here[/url] is a great link to some guy names LazyFoo. He has some awesome tutorials on learning how to use SDL with C++, definitely worth looking at. Good luck!
  6. I have an [url="http://breinygames.blogspot.com/2012/06/generating-terrain-using-perlin-noise.html"]Island Generator[/url] that generates islands that look similar to this: [img]http://4.bp.blogspot.com/-U03l0yXpeIs/UEMleEgeDVI/AAAAAAAAAOI/_GxssdtK1VU/s1600/Screen+shot+2012-09-02+at+3.21.19+AM.png[/img] It's pretty obvious to tell where the deep/shallow water areas are, but the green areas represent a transition of grassland to dense forest, with the darker green areas representing more dense areas of forest. The islands are pretty cool and the generator is very consistent so I'm happy with all my hard work on it. I've also completed the next step of turning the islands generated into full-scale tiled worlds for a game I'm working on. My problem, however, is I actually don't have a great idea of how to do the tree placement on the tiled map for islands like this. How can I place the trees more spaced out in the lighter green areas, with them more close together in the darker green areas where the forest is supposed to be more dense? Any suggestions would be great! Thanks in advance.
  7. Kind of stuck in learning.

    If you are set on using C++ and feel confident in that language, look into doing some 2D game programming with SDL or SFML. I'm sure your computer would be able to handle both of those libraries. SDL is fun, easy to learn and software accelerated. Later down the road if you end up with a computer that actually CAN handle OpenGL, you can use OpenGL to do all the rendering with SDL or SFML to handle the user input, etc.. So I would get familiar with SDL/SFML, since later you can and OpenGL to either one of those. It's probably a better idea than jumping straight into OpenGL in all honesty. I wouldn't recommend that for beginners. If you aren't so set on using C++, I would look into learning Python with Pygame for 2D game programming if you're just starting out.
  8. 2D Map/Terrain Editor recommendations

    You could always write your own Map Editor, and just draw out all the tiles you want to use in any image editor like Pain/Photoshop/Gimp. Writing your own takes a little bit of time, but it would give you a better idea of how handling maps for 2D games works and the different concept you could use. I definitely wouldn't recommend loading one giant image for your map though, remember with tiled maps you can create entire worlds from just a handful of images. It takes more memory to load a really big image, than a small handful of 32x32 tiles. Servant of the Lord has a pretty good explanation of how to implement tiled maps for your game [url="http://www.gamedev.net/topic/629742-2d-overhead-tiling-engine/"]here[/url]. Writing a map editor would be the same concept, but instead of loading the map data from a file you make in a text editor, you would save out the map data to a file depending how where the tiles are that you placed. Let me know if you have any more specific questions on how to do this if you're interested, it's actually really simple pretty efficient. I did this recently for my game, here is a [url="http://3.bp.blogspot.com/-An8mjf4uq18/UCv-IMouTJI/AAAAAAAAALM/xXpxS5u9Sgc/s1600/Shadow+Island+BEFORE+Tile+Blending.png"]screenshot[/url] of it that shows what tiled maps can produce. Taking the tiled map approach as opposed to the "saving one big image" approach, has man more advantages than just taking up less memory. With the data for each tile that your custom world editor (that you could easily write), by creating a Tile class you can store more information than just the tile's image. You can store the location on the map, the type of tile it is, weather or not it's a walkable tile (or drivable if your doing roads and such), etc. That makes collision detection a lot easier in the long run vs having to go in and hard code all the areas that you can't walk/drive. You could easily implement a basic tile blending algorithm to make the transitions between your tiles smooth if that's what you're looking for. [url="http://3.bp.blogspot.com/-kxxn40034Z4/UCv-GfW_XtI/AAAAAAAAALE/q0g_gvxTk4k/s1600/Shadow+Island+AFTER+Tile+Blending.png"]This[/url] is what the above screenshot would look like with an image blending algorithm for the tiles. I understand this can be a little confusing at first, but I promise it's really not a difficult concept to implement. Let me know if you need any more specific help or have any questions!
  9. RPG Items management

    What I've done for my game, that has worked perfectly so far, is have all of the items instances of s single item class. When you create the instance you pass a string which is what type of item it is (this would be your unique identifier, ex. weapon, potion, armor, shield, boots, helmet, etc), the name of the item (to load the appropriate image file), what 'level' it is, and it's position on the map. Keeping all the items in one class keeps my code my more clean than having a lot of different item classes. I also have a stats generating function that generates random stats for each item depending on what level it is and what type of item it is, that way I don't have to hard code the stats for each one. You could also hard code the stats for which ever more specific items you wanted (ex. there is only one 'electric dagger' in the game with a damage of 30 and a required strength of 40, or whatever). You could implement something like that as well to ease the issue of hard coding each stat for each item. You could easily play around with different stat generators, rare item generators, etc. It's actually pretty fun. I just finished the whole weapon/item and inventory system for my game. Customizing the organization of the items in your inventory by dragging them around each slot, equipping weapons/armor, using hp potions, dropping items, etc all becomes 100x more fun when you programmed it all by yourself. Good luck man! Message/Email me if you have any more specific questions. This is all still pretty fresh in my head, I've spent the last few days going at this.
  10. Need Help Making a map

    Tiled maps are definitely the way to go for what you're asking. Try something like this: 1) Load the data from a .txt file that looks something like this: 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 2) Loop through the data from the .txt file row by row. For each 1, add a wall image, for each 0 add a floor image. Add the image to an array, with each row as its own array. Putting all of the rows in order, and another array. That makes a 2D array which would represent all of the tiles of your map. 3) In your main game loop, loop through your 2D map array, rendering each tile image at the appropriate position. I would even consider going as far as having a tile class, to create tiles for your 2d array that hold not just it's image, but also it's position, weather or not it's a walkable tile, etc. Stuff like that. That's just a basic idea of what I would recommend, and the above would only display a room, but thats the concept. Tiled maps are actually a lot more simple than people think! Also if you like the idea of tiled maps, when you become more familiar with them, a really interesting topic is random map generation for generating random dungeons, caves, etc. That way you don't have to load a .txt file, it's all generated. It also give each new map a whole new feel but uses the same tiled map idea. If you're interested at all here is a guide I wrote on 2D tiled random map generation. [url="http://breinygames.blogspot.com/2011/07/random-map-generation.html"]http://breinygames.b...generation.html[/url] It would be a pretty cool thing to implement in a pokemon style game. Good luck!
  11. Pygame Image Problem

    [quote name='Steveway' timestamp='1345915033' post='4973284'] Let me guess. You are using a Mac. This is a bug in the apple-provided png-loading routines that pygame uses on macs. AFAIK this has been fixed in current versions of pygame, you should get a newer version for your system. [/quote] Yep, I just figured this out. When I open the image back in photoshop instead of opening it using the standard 'Adobe RGB (1998)' color profile, I tried opening it in the 'Apple RGB' color profile and opened the image EXACTLY how it looks in-game. So I guess it has to do with how pygame loads the images on Mac, the problem is I have the most updated version of Pygame. Not sure how to fix it now :/
  12. Pygame Image Problem

    [quote name='Esys' timestamp='1345914250' post='4973279'] What image format is the original picture? Have you tried changing that? I've found that bitmap images are affected less by pygame's convert(). [/quote] The image is .png just like all my other images I've been using. I tried re-saving the image to .jpg, and .bmp with 8, 16, 24 and 32 color depths each. I've tried so many different things! Haha. Nothing is working!
  13. Pygame Image Problem

    [quote name='Servant of the Lord' timestamp='1345912990' post='4973272'] Are you mistakenly creating the window with a color-depth (or bits per pixel, bytes per pixel) less than 8 bits per color channel? How do you create your window? Are you mistakenly altering the transparency/alpha-component of the images? Change the background color to bright pink and then see if that effects the color of the rendered image - if it does, it probably has some accidental transparency. Both the images you posted above are from the same computer right? One is the actual image, and the other is an actual screenshot of the actual image as seen in the game? [/quote] Yes, both images are from the same computer, the brighter image is the actual, the duller one is a screenshot of what pygame is doing. I did change the background color to bright pink to check from any transparency mistakes, that's also not the issue. It does the same thing! [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img] And this is how I'm creating my window: [CODE] screen = pygame.display.set_mode(resolution) [/CODE]
  14. I've been working on the HUDs for my game, more specifically the Health, Mana, and XP bars that will be displayed at the bottom of the screen. So I drew up an image in photoshop for the health bar that looks like this: [img]http://3.bp.blogspot.com/-1kC9Bem86xk/UDj44cTufbI/AAAAAAAAAMM/UF4uhW-a5QY/s1600/Screen+shot+2012-08-25+at+10.03.10+AM.png[/img] But for some reason the in-game image looks like this: [img]http://2.bp.blogspot.com/-V6FVtEAULFk/UDj45YW5RfI/AAAAAAAAAMU/hdJ-SDBjqO4/s1600/Screen+shot+2012-08-25+at+9.50.17+AM.png[/img] As you can tell it is does not match the correct one, and its a little frustrating because in-game it looks too dull. I'm not sure why Pygame is doing this? I'm using the very standard pygame functions to load and render the image: [CODE] pygame.image.load('image_path').convert() [/CODE] and [CODE] surface.blit(hp_image, (position.x, position.y)) [/CODE] Now that I've noticed it, it's actually doing it to a lot of my images! If anyone knows why, please let me know. Thanks in advance!
  • Advertisement