• 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.

trjh2k2

Members
  • Content count

    53
  • Joined

  • Last visited

Community Reputation

393 Neutral

About trjh2k2

  • Rank
    Member

Personal Information

  • Interests
    |audio|programmer|
  1. You need to pick the language/tools/tech to match whatever project you're actually trying to put together.  "A dynamic website" can mean so many different things.  If you've never made a website of any kind before, it would make more sense to start with plain HTML, then add Javascript once you're ok with HTML, then move onto PHP once you're comfortable with static pages and have a better idea of what your requirements are. A good tool for local testing / dev would be something like XAMPP- it's basically a really easy way to setup a web server.  Install it, hit the "start" button next to Apache, put your site in the /htdocs folder it makes, then access them by typing "localhost" into your browser.   Your PHP scripts will work this way.
  2. That's news to me.  If you're comfortable in C and the tech you're already using, I don't see any reason to switch to being a browser game "just because".  Web games come with their own set of challenges and constraints that may not play well (pun slightly intended) with your existing game design. No platform is going to be permanent at this point.  Even consoles rely on some sort of distribution platform that eventually will stop being supported.  I think you'd get more longevity out of native apps though.  Super old natively-running games can still be downloaded on steam or gog, etc., but web-based platforms come and go pretty quickly from what I've seen. My 2c is to stick with C and SDL.
  3. Use of matrices in this way has nothing really to do with how many dimensions you're working with.  One way or another, you still need to transform the stuff you're drawing into screen space.  Using matrices, or using specifically world/view/projection matrices is just one way to do that.  In 3d it's probably the most straightforward approach, but in a 2d scenario, your "projection" probably isn't doing anything, and if your camera only ever pans around, it might not be doing very much either.  And again, if everything you draw is axis-aligned, never rotates, etc. then all of your math is potentially very simple. Objects in any game, 2d or 3d are going to be made out of primitive shapes on some level.  In a 2d game you could get away with creating one quad and redrawing that same one with a different transform and texture on it.   You don't need to "import a model" to just draw a textured quad.  I'm not an expert in rendering though, so someone else I'm sure could recommend a better approach, or fill in the details that I don't know off the top of my head.
  4.   ^ This.  There are enough games out there to pick from that I'll skip stuff most stuff that can't be played comfortably from a couch with a 360 or Steam controller.  That includes anything where the UI is too small to read from a bit of a distance.
  5. Why not?  I see no reason you couldn't make a game that amounts to just alternating between a question and some other activity.  It could be an interactive story game where the story branches based on whether or not you answer questions correctly (no pressure, no reflexes, and no "lose" state, but the right answers give the "good" ending).  It could be an endless runner where maybe after running for a short time (maybe you have to jump x number of obstacles), you need to answer a question to open a gate, then continue running again.  I think your age range might be too wide for a catch-all education game.  A 3 year old and a 7 year old are going to be very different in terms of what keeps their attention, and what challenges them.
  6. I've got nothing to add in terms of machine spec, but I'll vote for getting as many screens as possible.  I like three screen because at three, everything has a purpose- Screen one has my ide/code/etc. Screen two has my tools/engine/game/etc Screen three has non-work stuff, spotify, maybe a browser, etc. I like the idea of doing the work on one screen, seeing the result on a second, and keeping potential distractions on the third
  7. I don't think you were ambiguous, I just disagree with you.  I think Undertale has a very intentional visual aesthetic, and I don't doubt that a lot of work went into it.  Just sounds like you don't particularly like the result, which is fine, you don't have to, but that's not any indication of the level of effort or care that went into it.  It's a game that screenshots do not do justice to.   Edit: It's also important to keep in mind that "being pretty" is not always the goal of art.
  8. I feel like this a projection of your tastes and expectations onto these games, rather than fair criticism.  A particular aesthetic doesn't need to be brilliant and over the top to be effective or polished.  There was a time when I looked down a bit on "pixel art" as "easy", but that's not really true at all.  The art in those games accomplishes what it needs to do, at a level of polish that's comparable to the other components of the game.
  9. Even in those situations, IMO, there would be higher level optimizations to make first that would likely negate the need to shave tiny fractions of time off the specifics of how iterating is implemented (assuming you even gain anything that way at all after compiler optimizations are considered).  Things like collisions or searches can take steps to reduce the number of things you need to iterate over in the first place.
  10. Just kinda thinking out loud, but it seems to me like if you've worked yourself into some kind of corner where you have to optimize how many instructions get spit out for using for loops, then something else is already wrong.  I can understand that some people are more comfortable working with structures and things that either make life easier, or make code more readable in exchange for some overhead, and I get that a literal for-loop is not always the most appropriate choice, but a lot of these sort of "utility functions" strike me as trying to out-smart the language, or be clever for clever's sake, with not much real world benefit.  Great, you've shaved a few micro seconds from your iteration code - but the real problem might be that you're iterating over too many things in the first place, since we're optimizing loops instead of optimizing the actual content of the game scene or whatever else have you.  ¯\_(?)_/¯ To be fair, I do spend a lot of time in javascript-land where people invent all kinds of "clever" nonsense- trying to recreate features of languages they're more comfortable with, or trying to turn every tiny function of a system into "modules" with all the overhead and process and dependencies etc. that go along with it *cough*node*cough*. I won't claim to have anything really valuable to say about which approach is reaaaaaally "the best" way to go in this specific case, or which is really faster or more correct, but I'm usually very leary of code that's trying to be "clever" when there was no good reason not to use a straightforward approach in the first place.  Just my 2c.
  11. I think there's a point to be made about not aiming only for AAA studios.  There's lots of work to be done for smaller companies, and given the things you've raised as concerns, you might be better suited to a smaller company.  Job security is maybe a bit better but still kinda the same, pay is usually a bit less, but otherwise in my experience there's less to worry about in terms of burnout, crunch, not enjoying the work, etc.
  12. Like any other 'art', whether or not it's "too offensive" comes down to why you're making it in the first place.  If you're trying to make some kind of point, then the level of offensiveness is probably intentional and "too much" might be exactly what you want.  If it's meant as a "lol it's funny to do offensive stuff", then that kind of humour will fall flat with a lot of people (myself included) and if your game gets any traction, it'll likely receive a lot of heat from people who really don't find it funny, and a lot of support from people who share the sense of humour or like to push boundaries. I think the part you need to be careful with is not so much the level of offensiveness, but how you handle and justify that content.  If you say "I want to explore these experiences in a safe way, create something introspective, make a point, etc" then that's one thing, but if you handle something offensive as if it's a joke, or pass it off as "lol, just kidding, just a joke, just an experiment, just a prank", then you'll likely experience very different reactions.
  13. Not really adding anything new, but I'll jump on the "they're both good, but use the appropriate tool for the job" idea. I've used both, and prefer UE4 over Unity, but I'm pretty sure that's just because I prefer that workflow (and appreciate the full source access).  To me, Unity is sort of this black box, and I don't always trust that it's doing what I want, but with Unreal, I can just dig in and figure out exactly what it's doing.  On the other hand, I feel like Unity provides a very "fast" way to work, and is a little more non-programmer friendly for some tasks. For a huge fancy high-performance, crazy graphics, FPS, all-the-buzzwords kind of a game, I'd go for Unreal right away cause I can't think of a reason not to.  For a smaller, more casual game, where performance is not as important, but things need to be done quickly, I'd go for Unity.  For in-my-free-time projects where I'm the only one working on the game, I tend to roll my own "engines" for the sake of learning how all the pieces work, challenging myself, etc., since time is not a concern.
  14. For VSTs yeah, probably.  I don't do much with virtual instruments, but I've gotten a fair bit of use from the free TAL stuff.  For learning, that could be a good way to go- costs nothing to play around with it. Nah, go for it anyway.  Free/cheap stuff is not "bad".  I've produced a couple of albums, and a tiny bit of music for games, using mostly free VSTs.  Reaper is not an inferior product to other DAWs by any means- it just doesn't have a lot instruments bundled in, and some of the built-in plugins are a bit ugly to looks at (the ui is simple, but the sound is what's important), so you'd have to find plugins to do some specific things, but that's no reason not to dive in. Another route might be to find any generic MIDI editor, or one of those apps that does guitar tabbing, and use those for composition, then import the MIDI into whatever you're comfortable with for mixing and instrument sounds.
  15. I've never tried a VSTi in Reaper that didn't work.  ¯\_(?)_/¯  But you're right, there's basically no built in instruments, but there are free ones out there. Maybe there are better tools for the job, but probably not for the asking price of $0 (initially at least) for a great full-featured DAW.  FL is probably a great tool for more of the midi/loops kind of editing, but it's more expensive, especially if you want the full-featured version.  As soon as you start looking at much else, price goes way up as far as I've seen. To be fair, I haven't done much shopping around for DAWs either recently, so if there are reasonably-priced alternatives with a similar feature set, I'm all ears.