• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Magdev

Members
  • Content count

    19
  • Joined

  • Last visited

Community Reputation

197 Neutral

About Magdev

  • Rank
    Member

Personal Information

  • Location
    Everett, Washington
  1. Ooh. I understand. Yeah, I'll definitely try that.
  2. Strength is just a constant between 0 and 1 that I define in-code which is just the strength that the camera follows the player. No time variable is needed.   That's not related to the jittering problem, but it can be a problem for some people. I don't see it as a problem though. I don't think it's even possible for the player to move fast enough to leave the camera's view, but if it is, it's not really a big deal. If it becomes an issue then I can just constrain it.       Yeah, it does seem like the nature of the system. I have a few workaround ideas in my head, but at the very least, the first fix did make it pretty acceptable and not very noticeable. The jittering how it is now is exactly like Cave Story's jittering, which is barely noticeable, which also reinforces how it's probably not worth fixing further. Thanks a lot for your help.   If I come across anything that makes it better, I'll post it in this thread.
  3. The camera position code is in the first post.
  4.   Ooh. That makes a lot of sense. I did what you said and it fixed the jittering during constant movement, but there's still jittering while the camera builds up to the player's speed.     I ran the game at 10% speed and output the camera's delta and position, holding a key to mark the jittering frames when I saw them.      It's not super accurate because of my timing, but it seems like it only jitters when the camera moving more than one pixel per frame. The player moves at a constant speed of 1.5. When the camera is at 1.5 delta, it alternates between one pixel per frame and 2. Not sure how helpful this information is.   I could possibly clamp the camera speed below 1, but that's probably too slow, and just a workaround rather than a fix. Any ideas?
  5. I'm making a 2D sidescroller in XNA  and I'm having an issue with the way the camera follows the player. When the player walks left or right, and its walk speed is a decimal number, there's jitter.   This is what it looks like. I had to slow the game down to 50% speed for the gif to catch the jitter frames. (Ignore the random vertical twitching, that's just some strange graphical bug that happens when I scale the backbuffer up too far.)   I believe the cause of this is the relative speed between the camera and the player. In the gif, the player's speed is at 1.5, so it will alternate between moving one pixel and two pixels per frame. This causes a sort of desync between the player and camera movement which causes the jitter.   I need to be able to use decimal speeds because first of all, a speed of 1 is a bit slow for the player, and 2 is a bit fast, but also, if I add acceleration/deceleration the player's speed won't always be a whole number.     Some details:   - Nothing is rounded in-code. All positions and velocities are floats. Rounding isn't needed since nothing can move in sub-pixels. I reduced the backbuffer resolution so changing an object's position by 1 will move it one pixel. Everything is drawn at integer positions, of course.   - It's not the update order. The cycle is simple right now. The player moves, then the camera is updated. Switching the order doesn't fix the issue.   - I remembered that Cave Story has nice and smooth camera interpolation, and large pixels, so I fired it up to see what it looks like, and I was really surprised too see that it suffers the same problem. For roughly a second after the camera starts moving, the player jitters by one horizontal pixel.     My camera movement interpolation code is this: if (camPos != playerPos) camPos += (playerPos - camPos) * strength;   Any ideas on how to fix this? I'm sure SOMEBODY has had this issue before other than me (and Pixel).   If I need to include any more relevant code snippets, just let me know. I can't really think of any that would help at the moment.
  6. I was really addicted to videogames in elementary school. I remember constantly pulling all-nighters on school nights to play Gunbound, Maplestory, Ragnarok Online, and Dark Ages. It was really unhealthy. I remember staying up for so long without leaving my chair, that when I went outside to check the mail I felt all woozy and confused from the light. It pretty much continued all the way until high school. It wasn't as extreme, but I always had mediocre grades as a result. It's not all bad though, being on my computer as much as I possibly could opened me up to all types of genres of games, the indie game industry, and some forums which slowly brought me towards wanting to be a game developer. I've been focused on working on my games so much lately, that I've only played a few of hours of videogames over the entirety of December. It feels pretty nice staying on track and productive.
  7. You can try f.lux, which tints your screen and makes it much easier on your eyes. It's ideal for long programming sessions. You could also try changing the colors of your IDE to be darker. I'm not sure what IDE you're using, but IntelliJ's dark theme is really easy on the eyes. Maybe you could configure your IDE to look like it. http://i.imgur.com/PlY2X.png
  8. Mostly videogame music, particularly the Nier OST, the Cave Story OST, the Shadow of the Colossus OST, the Chrono Trigger OST, OCRemix stuff, and stuff from composers that I like such as Goniochromism, sevenee, Flashygoodness, and Disasterpeace. I also like having the Mega64 podcast on my second monitor but sometimes it distracts me a lot. Totally worth it though.
  9. [quote]So I really don't like this class, and that's mostly because it is based on System.Random. System.Random is a fine tool for random number generation, but it doesn't offer any of the advantages of perlin/simplex noise. In particular, it is not continuous, whereas perlin/simplex noise is continuous even in its first derivative. This has a huge effect on the quality of generated worlds, and will become very evident if you ever implement per-pixel lighting. System.Random also comes with a number of other disadvantages. Chief among them is that it explicitly isn't guaranteed deterministic between .Net releases (or platforms) - there is a good chance that you will run your program on a different version of .Net, or a different machine, and you will get a completely different procedural world from the same seed value. Given that the OP already has a working simplex noise generator (I too use an implementation derived from Gustavson's code), I'd strongly suggest he stick with it. [/quote] That's agreeable, it seems that his issues lie in the implementation/use of the noise generator. I've tried generating a 1D heightmap for a base ground area, and it didn't look very good. What I recommend is that you generate a 2D noise map, then have a gradient influence it. Here's what I used when I was making a similar game: [url="http://accidentalnoise.sourceforge.net/minecraftworlds.html"]http://accidentalnoi...raftworlds.html[/url] In basic pseudocode implementation terms, you want to generate an array as big as your 2D noise-generated map, but with a gradient, where the bottom-most row starts at 1.0, and interpolates to 0.0 at the top row. You then loop through each value on the gradient map, and multiply the value of the cell respective to the noise map. When generating the tiles in your world you simply want to read the final result's map and only create tiles on cells that have a height value above 0.5 or something around there. That's how I did mine, and here's a screencap of the result. [url="http://i.imgur.com/ogyPS.png"]http://i.imgur.com/ogyPS.png[/url] You can also increase or dampen the amount the gradient influences the noisemap for some really interesting terrain. [url="http://i.imgur.com/UMXhP.png"]http://i.imgur.com/UMXhP.png[/url] [url="http://i.imgur.com/MfQmU.png"]http://i.imgur.com/MfQmU.png[/url] After generating a map a few times, swiftcoder's post is really proving to be true. I generated worlds about 20 times and they didn't vary very much, and sometimes they were nearly identical. Strange.
  10. @Sevvy325 Ah, sorry about that. Class: [url="http://pastebin.com/W56fjgry"]http://pastebin.com/W56fjgry[/url] Implementation: [url="http://pastebin.com/aKLfCE4n"]http://pastebin.com/aKLfCE4n[/url]
  11. There are several places that are viable to start out at. I'll recommend my route, which was to learn C#/XNA. XNA is excellent for beginners. I was able to make a few simple games with hardly any programming or C# experience, just diving it to XNA (probably not a good idea, by the way). I'm going to reinforce what BCullis said; pick something and stick to it! There are lots of resources floating around, even several books just for XNA. C# is much easier to learn and use than C++ when you're starting out, and is very similar to Java, so that'll be there if you ever decide you want to learn it too. With engines, you don't really want/need to write your own engine, but if you really wanted to, that'd come way later. I've been game developing for like 3 years and I haven't made/used a game engine. Just build your game and what you need for it. Game engines are very generalized to fit wide needs, which means you'll have lots of bloat that you don't need, and you won't learn as much out of it. This article is a pretty good read on the subject: http://scientificninja.com/blog/write-games-not-engines Aside from all that, BCullis' post covers pretty much everything else. Good luck!
  12. People do that to me all the time. I've never heard an idea that didn't make me roll my eyes. They often think I'm capable of making games up to par with corporate titles developed by a team of hundreds. I can't really blame them for not knowing though. During high school, there was a guy who actually wanted me and a few other people to make a game with him as the designer. He knew absolutely nothing about how game development worked though, so we all dropped out on the offer.
  13. As much as I don't want to say "Just throw all that away and use this class", but just throw it all away and use this class. http://hastebin.com/lojeremano.cs I've used it tons of times. It's fast, extremely easy to implement, easy to understand, etc. I can get a procedural world up and running in like five minutes in XNA this way. Here's an example of the implementation. http://hastebin.com/yuritaluqe.pl
  14. Having a character for each sign is a really bad idea. You should implement some sort of entity system so that you can add signs and other objects in the world separate from your tilemap. You gotta do it some time, right? Unless you don't plan on expanding your game past "The Adventures of Tinyguy: Rogue Sign-Reader Extreme". I recommend looking through some general tile engine tutorials as well. Good luck, mang.