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

GBGames

Members
  • Content count

    709
  • Joined

  • Last visited

Community Reputation

217 Neutral

About GBGames

  • Rank
    Advanced Member

Personal Information

  1.   Yes. Start with a small and simple game. Lots of developers get their start with trying to create and finish Pong, for instance.   Pong seems simple, but until you've actually created it, you might not realize all of the moving parts and under-the-hood work that goes into making such a simple game.   Otherwise, I agree with BaneTrapper in that if you keep at it, you can accomplish it.
  2. I haven't tried it, but https://github.com/ocornut/imgui looks like it is still being updated.   And there's Guichan but it looks like it hasn't been updated in forever.
  3. Perfect! I'm glad it worked out!
  4. It's hard to answer your question directly, but when I tried to implement it myself a few years ago, I ran into the problem of not knowing what data structure to use. I recall something about how using a list or a set or a vector wasn't appropriate, but I got something to work with one or the other.   You may want to take a look at how MicroPather does it: http://www.grinninglizard.com/MicroPather/index.htm   Also, Amit's website is a great resource: http://www.redblobgames.com/pathfinding/a-star/introduction.html and especially http://www.redblobgames.com/pathfinding/a-star/implementation.html which has three language-specific details.   While you said you know A* and just need to figure out the implementation details, it helps to look at other implementations, even if they are in a different language, as you get a sense of what's involved at the code level.   You basically need to start iterating through your nodes. You've got your start node and the concept of a current node, although since currentNode isn't initialized I'm not sure what "startNode = currentNode" is accomplishing. Maybe you meant to reverse the assignment?   Basically, you take your start node and add it to the open list (looking at your code, I bet you did mean to say "currentNode = startNode").   Then, go through your open list's nodes by popping them out (so they are no longer in the open list).   If your current node is at the goal node, great! You should have setup someway to say where this node came from, and you should be able to reverse your way to the nodes in your path.   Otherwise, get the neighbors of your current node and add them to the open list. How you add them is where the Manhattan distance comes into play, and this is why I said that the data structure used is important. In Amit's code, he uses a custom class called PriorityQueue, and he uses the cost so far and the Manhattan distance heuristic to determine which of the neighbor nodes will get processed first. Essentially, your code should try to pick the most likely candidate to be closest to the goal each time through. You'll be adding nodes to the open list as you check each node, but your calculation should allow you to say that one node is the best candidate in the open list.   In the end, Amit recommends using a third-party library if you just want to get pathfinding in your game. I would use Micropather.   But if you're trying to implement it for the challenge or the learning, it might be a good idea to try to implement his version, then modify it or rewrite it once you see how it all works together.   I got the book Artificial Intelligence for Games, and I tried to follow the pseudocode provided, but ran into issues with what the open and closed lists should be implemented with. My pathfinding didn't look great, but at least my entities got from point A to point B. B-)
  5. If you compile your program with the debug flags (-g) (oh, and use -O0 to make sure no optimizations are made), you might see more information that could be useful.   Obviously we can see that the crash is happening when your font is being deleted. With debug output, we might be able to see which line is being called at each point in the stack trace, which will help us narrow down what is happening.   Although now that I am looking at your main function, here's my educated guess at what is happening: you are calling deinit() before your font is getting destroyed.   You call init(), which initializes all of your subsystems for SDL, then you create your Window, Player, Font, and Text objects on the stack.   But then you call deinit(), which shuts down all the SDL functionality, and when your main function exits, it calls the destructors on your objects in reverse order of when they were created. The Text object has an uninteresting destructor, so it's fine, but then your Font object calls TTF_CloseFont(), yet you've already called TTF_Quit().    You should probably ensure that deinit() is called after your resources are finished using SDL functionality. The two ways to do it would be to enclose everything in main after init() and before deinit() in curly braces so that it has its own scope (my preference), or use pointers and make sure to delete the objects before calling deinit().   With the enclosing scope, you can guarantee that objects created within that scope, like your Font object, will get destroyed when that scope is exited automatically, and then your deinit() should be safe to use.   Let me know if this information helps!
  6. In gdb after it crashes, can you type "bt", hit Enter, and show us the stack trace it prints out?   I tried to pull down your code and compile it myself, but my gcc is older. I need to update my system, and I won't be doing so anytime soon.
  7.   Have you been able to run your program in gdb or another debugger? I find that it sometimes shows me exactly where things went wrong, although in this case I wonder if the crash is separated from the introduced problem. Valgrind is also a good option if this is a memory issue, as it can tell you if you have issues with memory management.   Looking at font.cpp, I see that you do TTF_CloseFont on your pointer before you assign a new font to it, so that seems correct. Your destructor runs TTF_CloseFont(). Is it possible that the mFont is already closed by this point? The docs don't say what happens if you call CloseFont on an already closed font, so I am not sure what may happen. Sounds like a good experiment to try.   Oh, I just saw that your Builder::deinit() is calling SDL_Quit() before TTF_Quit(). SDL_Quit() should be called last. See https://wiki.libsdl.org/SDL_Quit "If you start a subsystem using a call to that subsystem's init function (for example SDL_VideoInit()) instead of SDL_Init() or SDL_InitSubSystem(), then you must use that subsystem's quit function (SDL_VideoQuit()) to shut it down before calling SDL_Quit()."   I hope this helps!
  8. Quote:Original post by KulSeran Now, I've never had to make any installers for my applications yet. But I've been doing a lot of work in linux, and the install process itself is a breeze compared to the windows installer. While you're right about package managers making the experience easy for GNU/Linux users (Synaptic is a GUI that makes apt-get install even easier for the CLI-timid), there are two things to note: 1) Making an installer for a GNU/Linux is hairy by comparison to using one. Do you create .deb/.rpm files? Do you create a .sh script? Do you simply pass along a tar.gz file? Once you made the choice, except for the last one, good luck finding an easy way to do it. Debian and Ubuntu use slightly different formats for .deb (not enough to make a difference in most of the apps I have ever installed, but it's a warning I see enough of), and the creation requires intimate knowledge. If you give someone a tar.gz file, it's expected that they would do the trinity of ./configure && make && make install, and autotools has been a bear to get my head wrapped around, to the point that I think I'll have an easier time just paying someone else to create the installer for me. 2) Regardless what you offer, people will complain that you didn't offer what they prefer. Some people prefer installing apps using the package manager. Some prefer the autotools way. Some prefer a GUI installer so they could click Next over and over until they're done. Some prefer to install without a GUI. And if you offer all of them, you'll confuse some people you just want to download and install your game without complication. I used NSIS to create an installer for a game, and while the actual config file was relatively straightforward to create, I was told that users found that their antivirus would see it was some kind of threat. I think it is because NSIS is probably so commonly used that viruses use them and so NSIS files become triggers. Installers are definitely a pain. BitRock tends to show up at The Linux Game Tome often enough, and it seems to be a proprietary, cross-platform installer that is supposed to be intuitive. I've never used it, though.
  9. I am not a Mac owner, but I do remember that Apple put up Developer Connection: Games on the official site. It looks like it has a wealth of references, guides, and mailing lists. Good luck! EDIT: Oh, and you may want to check out Make Mac Games, a blog from a Mac game developer
  10. I've been using the Kyra Sprite Engine, and I am trying to build a custom version of it for my project's distributable. It depends upon SDL and SDL_image, and I created custom versions of those libraries, passing configuration options to them to remove a lot of dependencies. When I configure kyra to build, I pass in some prefixes for my custom versions of the SDL libraries. When kyra builds, it creates two libraries, libkyra and libengine. libkyra builds with the correct SDL libraries, but libengine uses the system installed libraries. I figure that there is a problem with how autotools is configured for this project. It used autotools a few revisions ago, but the current revision is actually a broken build. See the help forum on Sourceforge for more information on what is needed to build it and the issues I am encountering. I would really love some assistance with this problem. Either my understanding of the problem is wrong, or I just don't understand autotools enough to get it to do what I expect it to do. Thanks in advance for your time!
  11. According to the roadmap, they've added some languages to it already. That website might have more information about how to display Russian text in xmms.
  12. Someone passed me a copy of a LiveCD the other day, and I was able to get AIGLX and Beryl to work on my laptop. I know what I am going to be installing on that machine. B-)
  13. Is that Xgl? Nice.
  14. Quote:Original post by Mr Grinch Quote:Original post by GBGames Crown and Cutlass! Why does that game sound and look familiar? Has it been featured in linuxgames.com or tuxgames.com? We are in the Linux Game Tome, but I don't think we've had an update there for a long time. That's probably it! Roots: That's some great progress! Have you posted it to happypenguin.org?
  15. Crown and Cutlass! Why does that game sound and look familiar? Has it been featured in linuxgames.com or tuxgames.com?