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

Sijmen

Members
  • Content count

    689
  • Joined

  • Last visited

Community Reputation

231 Neutral

About Sijmen

  • Rank
    Advanced Member
  1. I haven’t been into game programming for a long time, but I read up on entity/compent/system and thought it was an interesting idea. As an exercise, I’ve set up a basic framework to get this working: void Game::load(ILoader& loader) { scene.spawn( PositionCp { {0, 0} }, VelocityCp { {0, 0} }, CollisionRectCp { {100, 100} }, ArrowControlCp { 150 }, TextureCp { "sprites", {100, 100} }, TextureSliceCp { {0, 0}, {100/256.0, 100/256.0} } ); scene.spawn( PositionCp { {200, 300} }, VelocityCp { {-120, -60} }, TextureCp { "sprites", {100, 100} }, TextureSliceCp { {100/256.0, 0}, {200/256.0, 100/256.0} } ); scene.run(LoadTextureSys, loader); } void Game::update(const UpdateContext& context) { scene.run(ArrowControlSys, context); scene.run(MovementSys, context); } void Game::render(IRenderer& renderer) { scene.run(RenderQuadSys, renderer); } At this point I’m a bit stuck. How do you go on from here to model game behaviour? The classic “If X happens, do Y” doesn’t really seem to map well to this design. I’d be super happy if someone could lay out some basic principles or points me to an article that does so.   One thing in particular that I’m wondering about is how specialised you should get with your components and systems. In this code I already have an “arrow control” component and system, but it seems to me like that wouldn’t scale. I read an article on building bomberman on an ECS design, and it seemed contrived for that reason. I’d imagine an engine would supply a set of generic components and systems, letting you basically script the rest on top of that. Is that a common approach? How would that be implemented?
  2. Hi all, I made this small gravity testbed to play around with: [url="http://labs.sjmulder.nl/ohgravity"]http://labs.sjmulder.nl/ohgravity[/url] source at: [url="http://github.com/sjmulder/ohgravity"]http://github.com/sjmulder/ohgravity[/url] What I was expecting/hoping to happen was for the bodies to do some buzzing about until finally collapsing. However, this isn’t really happing, instead the bodies slowly get more and more energy. Do they not know they need to observer the laws of nature? In all seriousness, what seems to happen is that when two bodies get really close together they gain a whole lot of momentum, more than is recovered from the mutual attraction as they fly off. Any ideas on where to start looking to fix this? edit: best visible with two bodies: http://labs.sjmulder.nl/ohgravity/#num=2
  3. As previously mentioned, sometimes it's more efficient to the system to pad every scanline (row of pixels) with a few bytes before starting a new line. So when trying to locate a pixel in memory, you should use y * pitch + x.
  4. (I'm on Mac) I'm recording to AAC which has great quality and is easily decoded which makes editing tasks much quicker. Then I load the AAC file in Final Cut Express where I edit it. I usually export to 640x480 H264 and with 48KHz sound. I've found that this setting yields a video for which YouTube will add a 'high quality' version.
  5. There are some really interesting ideas here. Still it seems there's not one well-established way to have large-scale, expensive software projects without charging for copies, apart from open source software which is a wholly different beast. Quake Zero is interesting. It's quite a high-profile game, but I'm not really sure whether something like that is viable for offline games. Maybe web-based ad-supported games have the future, but I doubt it.
  6. Wow that's pretty cool. I really like it.
  7. In business to business situations, one business pais another business to make software. Software is written to specs, delivered, and paid for, done. The payment for the effort and time of the programmer is very direct. Now as for b2c apps like games and standard software, it's a different scenario. People don't team up and pay to have a developer make a game they like, it's the other way around. The developer makes the application, and only THEN people find out about it and want it. Here we have a problem. As the people don't team up, they can't make a deal with the developer, pay a sum of money for the effort and time, and have him put it up on FTP or BitTorrent. So the developers found another way to be paid for the effort. It's obvious that the people who take most advantage of the work pay. That leads to the obvious way of earning from software right now: have the users pay for a copy of the software for them to use. But I have some concerns about that method: Making a copy is extremely cheap, which makes people reluctant to pay for the copy. They don't see that it's the effort and time they are paying for. Which leads to... The amount of people buying the software is not parallel to the time and effort, just to the popularity (and honesty of users). This does not need to be due to quality. It limits the amount of people that will be able to use the software. This is bad because I want the whole world ot use my software. So what are the alternatives? Not expecting payment for time and effort. This means the developer takes another day job (or be/get rich otherwise). Have users team up and 'buy' the program. I don't think this works. People want to see it first and then pay, not the other way around. Get some other business to pay for the software. The business would need some benefit, like ads or having some use for the app themselves. Donations. I don't know whether this is viable. ...? My question is whether any of you know some other ways of living off software development for consumer apps without charging for copies?
  8. Grekster, I'm pretty sure British English will be more than enough to get you through the checkout at a supermarket ;)
  9. I'm the Xst person to tell you, but you're not too old at all. Here's an anecdote: I've just graduated from a technical/programming course, and studying with me was this (at the time) 28 old guy who used to be a craftsman. From what I've seen, he was very good at what he did, but he wanted to do something totally different. So, he signed up for school and started learning. Over the past three years, he's gone from someone totally new to programming to a great programmer. He knows about different languages, is able to dive in unknown code and come out unharmed, and also does a great code design job. I would be mad not to hire him if I had a software development company in need of a programmer. (greetings to Walter!)
  10. What you could do is setting up a timer ever 1/30th of a second or so and call Invalidate() on your form in the timer callback, which will cause the window to repaint. By the way, the bitmap is now read from disk every time your window is redrawn. It's better to make myPic a member of the class and have it load in say, the load handler of your form.
  11. I have an alu 24" iMac at 1920x1200 with OS X and Vista. Suits me well for pretty much anything. I've had dual-screen for a while, but with this huge screen I don't really miss it :)
  12. I was thinking about just giving users the full, unrestricted app after paying. No copy protection, apart from authentication before downloading. Would that be economic suicide?
  13. Quartz 2D seems to be geared towards user interface and 2D graphics like the whole Cocoa UI, and 2D graphics like in edit views of drawing programs. I'd say OpenGL is your best bet, as you can count on it that it will get you all the hardware has to offer.
  14. Promit, great explanation. You're awesome.