Jump to content
  • Advertisement

The Geek on Skates

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

5 Neutral

1 Follower

About The Geek on Skates

  • Rank
    Newbie

Personal Information

Social

  • Github
    https://github.com/geekonskates

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The Geek on Skates

    Best gameplay mechanics/interface for text-based games?

    Okay, I apologize if I've asked tis in the wrong place. If I need to break it up into 3 different questions on 3 different forums I could do that... only thing is I'm actually not a beginner (I know C well and I've been writing software for 5-6 years now lol) so I may need to pick another spot for the cc65 stuff. Anyway, again sorry if I've stepped on any toes; I will do more research on the ideal place(s) for future questions before posting.
  2. The Geek on Skates

    Thoughts about a Project for Experience

    I think it depends on what kind of work you want to do. Obviously, wxWidgets and other GUI libraries are used in business software, and building a game in it is a great way to get some experience. But if by "work" you mean game development, I don't think a GUI library is necessarily the way to go. Most game libraries offer a lot more control than GUI libraries in terms of graphics capabilities. I've learned a TON of game dev tools, and there are basically 4 types: Low-level frameworks: These provide just enough of an API to draw graphics, handle player input (keyboard/mouse/etc.) and play sounds. Examples for C/C++ include SDL, SFML, Allegro, PyGame (Python) and HTML5 (JavaScript). If you're thinking 3D there's also OpenGL/WebGL, but IMO if you want to build a 3D game you'd go with... Enterprise game engines: These are big, robust tools that include "everything but the kitchen sink"; these are what the triple-A game dev companies are using (though there are probably some exceptions to that) and learning them is almost as big a task as learning game development. The big 2 examples lately are Unity (C#) and Unreal (C/C++). Others include Godot and Game Maker Studio (which has its own made-up scripting language). The occasional middle ground: These are few and far between; they're libraries that have more than just the basics, but aren't massive game engines. They support things like tiles, animations, rooms/scenes and other stuff that's important for games. I've been looking for libraries like this, and never really found one for C/C++ (which I've been assuming you want to use since you mentioned wxWidgets). In JavaScript, there's one called Phaser that's actually pretty darn good. Libraries: All of the above are less like libraries and more like frameworks - they dictate how your code is set up (to a certain extent), and the whole game structure revolves around their way of doing things. But you could use any combination of smaller libraries in combination, to structure the game your way. For example, I might want to use DirectInput for input, SDL for graphics, and OpenAL for sound (I don't know why you would want that, and IMO that's a stupid and weird combo, but it's an example). This is usually not done, except in companies that want to use their own engine instead of i.e. Unreal. It's really not great experience in game dev, but will definitely get you in the swing of learning how to link libraries, learning from API documentation/manuals, and other practices that are VERY common in software development in general. And actually, that's how 1 through 3 were invented - they just took a bunch of lower-level libraries and combined them in interesting ways to come up with something new. It's overkill IMO if you're a beginner, but I figured it was still worth mention. HTH
  3. The Geek on Skates

    Idea for an app but don't know where to start :(

    Hi Bianca, Phone apps are a bit tricky, because every platform uses a different programming language (Java on Android and Swift or Objective-C on iOS... oh, and C# on Windows lol), and also a different set of APIs ("libraries" of code for doing things like accessing the camera). However, there are options available that can simplify that a bit: If you know C#, there's an editor called Xamarin Studio that makes targeting multiple platforms a bit easier. If you know HTML/JavaScript, you could use something like PhoneGap or Apache Cordova (again, tools for targeting multiple platforms with a single code base). And actually, since you know Unreal, you might be able to build it for the web, and then put that in one of these. I don't know Unreal well, but I do know C++, so I know for a fact there's this tool called Emscripten (used under the hood of many games engines) that converts C++ game code into WebAssembly (like JavaScript but faster lol). Anyway, these are kind of over-simplifications, and I realize I just threw like a gazillion new tools at you, but if nothing else researching these should help you get past the "don't know where to start" phase. HTH
  4. Hey, happy Friday! I've been learning to use the cc65 compiler for 8-bit systems, and playing with simple text-based games in C. This has been a lot of fun, and the end result is I games that run on modern systems like Linux and Windows, and also retro systems like the Commodore 64! Eventually I want to learn 6502 Assembly and get to know the hardware of my favorite platforms inside-out and backwards, but you gotta start somewhere. Baby steps (lol). I even wrote a little library for that (I'll be open-sourcing it when it's finished - still buggy on Windows lol). And I'm a writer so this project has been a lot of fun! But now I'd like to take it to the next level. One great thing about text-based games is they actually have 2 niches where they're still relatively popular: (1) retro gamers like me, and (2) people who are blind. And since I'm just one guy and building games is not my full-time job, it just seems like the best fir for right now. And apparently, people are still creating them; there are some examples on my blog. But most of these are web-based, and some are extremely different from what you'd think of when you hear "text-based game". So I'd like to build some really good-quality text adventures, maybe make a few bucks on Steam or give them away on my website and throw in a donate button (lol); the idea of making money's not a real concern, but I do think I could create some cool games and I'd like to get them out there. But what makes text games fun? Obviously there's not a whole lot of documentation on the subject, cuz even small studios (5-6 devs) can do better than just text. And just because I may enjoy a game doesn't mean players will. So here are a couple specific questions, that I'd just like to get your two cents on, if that's cool: 1. How much description? For example, some games (like Zork) have a lot of description of where you are, what's around, and stuff like that. As a writer I think I naturally lean more in that direction, cuz even a little immersion in a text-based game is hard to accomplish otherwise. But on the other hand, some games described everything in 2-3 word sentences, and as a player I guess that might help move things along faster... but then again it could also be just because they ran on 2 KB of RAM (lol). But as a player, I could see where too much text could be boring if it's repeated too often. 2. What kind of interface? Some games work like what I have so far, where you type in short commands like "go north", but others do it in one key, like "n" for north. Words make it easier to do more (and you can have two commands that start with the same letter), but single-key commands can probably speed things up a bit. There's also a third option: menus. In some games you are given a set of pre-defined options, like those "choose-your-own-ending" books. Maybe it varies by genre? Like if I'm writing a story-heavy game, menus are the way to go; but if I were doing something more open-world, commands might be a better fit. And if there were any kind of timing involved, one-letter commands are best. lol idk, that's why I'm asking for your opinions. 3. Any example games I could try, or good places to get more info on the subject? I've found there are few good tutorials on the cc65 compiler, most of it's just documentation of the command-line options (which is a huge help, but not when you got questions about its headers/library, or which systems can support the standard C library etc.). And again, there seem to be even fewer on writing decent text games. Not to mention, sometimes the best way to find out what's fun is to goof off and play games (lol); so if you can recommend some good example games, I'd be all for it! But anyway, sorry for the stupid-long post, and have an amazing weekend!
  5. The Geek on Skates

    Library to emulate retro screens/displays?

    Haha I totally forgot about that! Yeah, that was an e-card I started on for my geeky friends (lol). And it did end up as the graphics component of a couple games. Now I hit the weird rectangle thing before too, and I solved it with: ctx.imageSmoothingEnabled = false; // Where "ctx" is a canvas element's "context" And I did get it up to near the "resolution" (aspect ratio?) you were describing. I think mind ended up working at 256x224, like the old (S)NES. But yeah, I do kind of wonder how the emulators do make the screens look so much like the originals. HTH
  6. The Geek on Skates

    SDL2 fulscreen - best resolution for retro 2D games on PC?

    Awesome! SDL_RenderSetLogicalSize was exactly what I was looking for. Thanks.
  7. The Geek on Skates

    SDL2 fulscreen - best resolution for retro 2D games on PC?

    Thanks for the quick replies! To the first post: I couldn't find "SDL _ RenderSetLogicalSize" in the SDL documentation or even on Google. Visual Studio's IntelliSense ("auto-complete") didn't recognize it either. I'd rather not get into OpenGL for simple 2D stuff; I think I'd sooner switch to SFML or Allegro or something that is built primarily for 2D before I resort to that. But good to know it can do that if I had to. I'd like to avoid black bars if possible. I knew they would be on the left and right at least, but I'd rather not have bars across the top and bottom (which was what would be necessary on weird resolutions like 1366x768. This leaves me with your first idea. "You can render to a smaller texture and then render that texture across the whole screen (being careful to disable texture filtering, or it will look horrible)." Would you mind explaining that a bit? I've never heard of anyone doing this, and I've only just got started with the Texture API; last time I used SDL graphics were rendered using Surfaces (so noobie question... texture "filtering?"). But this idea of using a smaller texture and then somehow scaling that to fit the player's screen is exactly what I've been trying to do. And to the second post, I appreciate the info on the hardware side. You're right, technically monitors themselves only have one resolution. And as a player I agree with you about borderless fullscreen. All the emulators I play (NES/SNES/Genesis/Game Boy/etc.) are basically in windowed mode, and I use Windows Magnifier to get that borderless fullscreen. But with those older games, that usually means the top or bottom of the screen is not visible. And with aspect ratios ranging from 4:3 to 16:9 it's not like there's a straightforward way to have borderless fullscreen on all of them. But what is this "viewport" you were talking about? I know HTML/CSS has this concept of a viewport, but that's the only time I've ever read that word.
  8. Hey guys, what's up? I've been building a 2D game with SDL, and I'd really like it to have that retro console/arcade look and feel. This mostly because those are the kinds of games I play, and have since I was a kid, but also partly because 8-bit sprites or (S)NES sprite sheets are about as good as I get in terms of graphic design (lol). But those old games had really small sprites, 8x8 at the least or 64x64 at the most. And of course, those old consoles had a surprisingly small resolution of 256x240. Another important note here: I'm really only targeting PCs for now; I know SDL can be ported to pretty much anything, but I only have my PC to test it on. I'm also using Windows 10 x64 and Visual Studio 2017, if that helps. So I started out by using "fake" fullscreen (passing SDL_WINDOW_FULLSCREEN_DESKTOP into the window creation functions). But this turned out to be a problem because SDL's drawing functions are pixel based. This is good IMOt, because it makes the math simpler and keeps the images crisper. But you can't get half-a-pixel, so scaling to fit the player's desktop is literally impossible in some cases. The end result is I had to draw black bars across the top and bottom, not just on the left and right. If possible I would like to avoid that, so I switched to "real" fullscreen (SDL_WINDOW_FULLSCREE). The lowest I could get it to go is 640x480, which is perfect (all image widths and heights can be multiplied by two to fill in the space). But is 640x480 still supported on modern monitors? The fact that it worked on my laptop is all well and good, but I'm afraid it would be a problem for others. I remember using Game Maker (before it was a "studio") back in the early 2000s and that resolution was not an issue back then. But is it still supported in 2018? My laptop is relatively new (about 2 years old), a Dell running at 1366x768 normally. If the answer is "no", what resolution(s) should I be using for this type of game? Thanks & happy Labor Day weekend!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!