Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 Jun 2013
Offline Last Active Apr 25 2015 12:31 PM

#5216886 Need help changing the date of a game

Posted by on 16 March 2015 - 12:06 PM

(Sorry, no idea about FIFA, but...) Study up on game ROM hacking (i.e.: SNES, PSX, whatever if need be) What you are ideally looking for when doing this sort of thing is called a "game trainer", AKA Game Shark for PC :-) Hex editor on steroids, basically. There's a piece of software called Bit Slicer for OS X -- https://github.com/zorgiepoo/Bit-Slicer -- that works well for real-time game hacking. Not sure about other platforms, but I'm sure you can find one fairly easily! Good luck.




#5216525 2D AABB Collision resolution and collision system/class design

Posted by on 14 March 2015 - 06:29 PM



I don't have yet any experience with anything past rudimentary collision detection, but I've been watching the Handmade Hero series, and skimming through your post reminds me of several key points that the series illustrates in great detail how to go about solving. Although his game genre is not a platformer, most all the math applies equally the same. 


Check out the episode guide -- starting at roughly "Week 10: Player Collision" and onwards; "Basic Minkowski-based Collision Detection", at an absolute minimum, should be watched. It might even be best to start at "Week 9: Vector Math and Player Movement", tough to say.




#5215598 Where do I begin?

Posted by on 10 March 2015 - 01:34 AM

If you are new to programming, I'd strongly suggest starting out with a higher-level language like Python or perhaps C# in order to familiarize yourself with the basic constructs of a programming language. All programming languages share the same basic foundation; program flow, algorithms, data structures and so on -- these are the things you should start getting comfortable with.

#5211062 What are the recommended places to store save data?

Posted by on 16 February 2015 - 04:29 PM

On Mac, the standard location would be ~/Library/Application Support/<app_name>. Another fairly common spot is ~/Documents/<app_name>. For saved games that you wish to access across multiple users: /Users/Shared/Library/Application Support/<app_name> or even /Users/Shared/<app_name>. For data that you shouldn't touch ... this sort of data typically reside in the application's bundle.

#5198960 Starting my own game engine - please don't laugh.

Posted by on 18 December 2014 - 10:56 AM

Wow, Eric Lengyel's advice was really inspirational for me! Thank you for sharing it. :-)

Don't be afraid to completely throw away some system you spent a lot of time working on and start over. If you're not under any kind of time pressure, it will be worth it in the long run.

I just wanted to try augmenting his advice here, saying just how important this cruel, but vital this can be for the success of the engine. No body enjoys throwing away code that they've poured blood and tears into, but you gotta do what you gotta do at the end of the day when the long haul is what matters. It reminds me of my difficult decision resulting in throwing away ~10k lines (in other words, ~3..4mo) of in-house GUI code in favor of an external library. Ultimately saved me a ton of time, I think -- ~3..4mo is nothing but a drop in the bucket in the long haul. After all, throwing away code is somewhat misleading, as you still retain all that you learned during the course of development.

#5198956 better way of loading images? SDL2

Posted by on 18 December 2014 - 10:20 AM

The ways you would go about not using a pointer still involve using a pointer, so you must still become comfortable with the concept in order to go about abstracting away the detail (a fancy term for hiding the implementation details). You cannot (sanely) change the underlying implementation to not use pointers, but you certainly can hide the fact that it does use them. The most common method of going about doing what you want is by creating a "wrapper" class that maintains the SDL_Surface pointer and operates on it internally (the fancy term for this is, I believe, "encapsulation"), but exposes a public API for doing the things it needs to do -- 99% of the time without ever needing to deal with the pointer. Doing so also has the side benefits of being able to conveniently do other things related to the task of SDL_image (such as conversion of image surfaces). Most importantly of all, it allows you to do the Right Thing ™ and perform the appropriate checks for error states that can occur.


For example, I have done just that in a class called Image (admittedly, not a great name for it!), that is really nothing more than a glorified SDL_Surface pointer with many convenience helper methods for working with the struct in a more pleasant manner, such as disk I/O, color keying, creation, etc. I would gladly share the source with you, but I'm afraid it would further compromise / post-pone learning about pointers, but if you insist... I suppose I would. It really does become obvious / trivial once you understand pointers a bit better.



In my current code, I use the "delete player" in order to stop some memory leaks. I use this on my images.



You are well upon your way to understanding, then! :-) Manually managing memory (pointers), in practice, often times boils down to: a) remembering to free it at the appropriate time; b) always ensure the pointer is valid (not NULL) before usage -- failure can include, but is not limited to, running out of memory, incorrect usage of the API and so forth. Easier said than done, sometimes. As for the first case (remembering to free) -- this is why **after** you have a solid understanding of pointers, people will often suggest considering the use of smart pointers when applicable; these help to eliminate the most common problem with pointers, and that is ... forgetting to free 'em! They aren't perfect, but no single programming tool ever is :-) (Note that "raw pointers" simply refer to the use of non-smart pointers). Whether you end up using them is purely preferential, in my opinion (that's probably going to be a very controversial opinion there...)


P.S. Although pointers may appear scary at first, I promise you that once that ah-ha! moment comes, you'll realize how beautifully simple they are :-) For me, I came to find out that it was just the syntax of the pointer that was "scary" (more like confusing in my case). 


My ah-ha! moment came when I realized that everything in a program is represented by a sequence of memory offsets, filled with values that you've set (sometimes indirectly), executed in the fashion you've set forth by jumping to and fro the memory offsets. Pointers do not hide this "secret" implementation detail, and let you manipulate these values stored in the memory offsets directly, whereas other language constructs do the same but through hiding that detail, to help facilitate ease of use. I apologize if mentioning this was a waste of your time, I was just trying to help facilitate your ah-ha! moment in the way that it helped me.


(Sorry, that must be like the longest P.S. ever written lol)

#5198510 Starting my own game engine - please don't laugh.

Posted by on 16 December 2014 - 05:53 AM

I'd suggest developing the engine around a game, and not the other way around, so to help prevent bloated, over-engineered APIs. It will give you an obvious and immediate "roadmap" at any given time. Major engine milestones / dev cycles (versions?) can be considered in terms of what it means to the game. A completed game then signifies an important evolution in the development of the engine.


I suggest this also because I've found even if you write unit tests that mimic the game for the engine during the development cycle of a feature, you'll never be able to anticipate everything. Game states are a wonderfully complex beast. Sometimes the issues are simple things like mere API usage, other times obscure bugs that only happen when in the context of a particular hierarchy of parts working together. In other words: engine tests represent theory, whereas a game represents practice.


Allocate time. Lots of it. It becomes an enemy that you can only win through accepting that you only have so much of it. Use it wisely.


These are a few of the many lessons I've been learning as I've delved into game development non-professionally in the past ~2 years, anyhow. Above all else, remember to have fun and often take deep breaths! :-)

#5195442 Critique My Implementation Of Pong?

Posted by on 29 November 2014 - 10:57 PM

If you are still interested in relocating magic numbers ...


A simple config file parser: Source Settings Parser from SFML wiki.




A simple JSON parser: JsonCPP. (I go with building my project with the resulting "amalgamated" source files).



#5194870 Introduction! And request for a tech tip

Posted by on 26 November 2014 - 06:08 PM

1. Violet UML (Java) -- haven't used this much, but does provide an acceptable UI under OS X. No idea about Windows nor Linux.


2. CMake w/ auto-generated project files for whatever IDE of individual's choice (i.e.: Xcode, Visual Studio, Unix Makefiles). It'll take a bit of time learning the basics of CMake and getting it to generate things the way you prefer, though. Alternatives to CMake might include Code::Blocks, Eclipse. Not familiar at all with those. Personally, I chose the CMake route, and it does works reasonably well, provided you are willing to spend the time on it (documentation on things aren't always straight forward). I auto-generate project files for Xcode or Visual Studio for when I need a debugger and use Sublime Text with build settings tailored towards clang and msbuild for use with building my projects from within the editor.

#5186042 Using same bundle ID for Free app? (iOS)

Posted by on 09 October 2014 - 12:57 PM

*nods* Yes, I believe so... each app **must** use a unique bundle ID.



#5184196 Data-driven design?

Posted by on 30 September 2014 - 07:24 PM

d:\sdl\include\rapidjson\reader.h(392): error C2228: left of '.Peek' must have class/struct/union

Does anyone know how to solve it? Maybe there's a better library for json?


Sorry, not too familiar with RapidJSON, but as far as alternatives... perhaps you may like JsonCPP ?

#5184191 Trading Card Game 101

Posted by on 30 September 2014 - 07:05 PM

For whatever it's worth to you, Hearthstone was built with the Unity3D engine.

#5110896 Game engine book?

Posted by on 20 November 2013 - 08:04 PM



If you already know what you're doing, then another book for beginners isn't going to help you.  Instead, study from the masters.

I whole heartedly agree! The great thing about the Internet is the vast and free resources for programming and virtually any other technical topic with computers). You need only desire, a search engine and a bit of luck.


I've been developing a game engine (nomlib's Github page) for the past year and personally have found SFML to be quite the inspirational source on good examples of general engine design, with an emphasis on simplicity / staying out of the way of the user. Perhaps the most valuable resource I've found yet is something I often forget: you can search for public project repositories from the Github web site (presumably also true of other web-based VCS?). Great for absorbing new ideas, brainstorming, etc. Related to my suggestions are open source projects in general, such as EASTL, Doom3 and so on. Lastly, studying general development aspects & principles: http://www.oodesign.com/ and http://sourcemaking.com/design_patterns