cdoty

Members
  • Content count

    445
  • Joined

  • Last visited

Community Reputation

733 Good

About cdoty

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1.   Bitcoin mining FTW! Until everyone starts doing it and a bitcoin drops to $0.06.
  2. Brain Dead Simple Game States

    I would also add enter and exit functions to allow the states to initialize data before use and to clean up after they are done.
  3. Most GUI libraries are terrible

      I'm looking forward to digging into this project. It looks like it may work well as an in-game UI for some stuff I'm working on.   Edit: I downloaded the project and was able to compile it.   Excellent job, The list of controls is extensive and well implemented, the data source stuff looks easy enough to use, and the code looks very clean and easy to extend, if needed.
  4. .. tomorrow World Domination!
  5. I want to know where to begin.

    Yes, as timothyjlaird stated, it's better to not start out with more than you can handle. Start out at a basic level, and add features as you learn them. Get into the habit of refactoring your code as you add new features; eventually you'll end up with a framework/engine that you can use and understand. Your code will expand as your game needs more features. This is the exact process I followed in developing Super Play.
  6.   Go a step above SFML (or SDL) and find a game engine that abstracts the hardware differences.   And now to push one on my projects on you.. Try my Super Play game engine (http://superplay.info/)  to develop a game that doesn't directly relate to the system you are targeting.   Super Play supports Windows, Linux, Android, Ouya, GameStick, and iOS by pretending to be a SNES that was created in 2013.
  7.   It will take years (and many cross platform projects) to find a design you are happy with.   I have finally gotten to the point where I do not hate my code layout with my Super Play game engine (http://superplay.info/).   For me I keep my 'global' interface in a class called either System or Platform. I depend on the project include directories to supply the location of files i need. The engine needs certain files from the game, which are supplied by the game project in specific file names.
  8. Most GUI libraries are terrible

    As long as you're only interested in simple UI (Confirmation dialogs, name entry, etc.), libRocket isn't too bad, but once you start implementing more serious dialogs (listviews, etc.) there is a lot of missing functionality.   The best UI I've found, assuming you're targeting Windows and don't need in-game UIs, is DuiLib: https://code.google.com/p/duilib/   It's easy to skin.   It would be ideal for a game editor, as the dialogs are created as separate windows. It also includes an editor which is useful for laying out the controls. Unfortunately the editor doesn't properly save all properties, requiring that you hand edit the XML to customize the control.   Here's a link that explains parts of DuiLib (It's in Chinese, but the translation is good enough to work from):   http://www.cnblogs.com/Alberl/tag/duilib%E5%85%A5%E9%97%A8%E6%95%99%E7%A8%8B/
  9.   I've followed about the same path, except for using a C-64 instead of the Spectrum. I used to copy pirated games to check out the demos I don't think I played most of them. I also developed a few demos of my own, I loved raster (and later copper) effects. I also created a nearly complete BBS program that was similar to C-Net.   Later I moved onto the Amiga and developed a few demos, but was never able to put everything together into a game. The jump from the C-64 to the Amiga was a huge jump in understanding software and hardware.   I moved onto dos and 16 bit consoles, and created more elaborate demos. After reading a few books (Gardens of Imagination and some of the Andre Lamothe stuff) I started to grasp the big picture items needed to put a game together.    After getting a game development job, and moving to C++ as my primary language (everything before was assembly, and some initial basic stuff), I started focusing more on the form and function.   I also finally put together my own engine, and now I'm enjoying the experience of getting it to run on different platforms. Surprisingly enough, I don't hate the layout of the code. But, I've taken the time to refactor, when needed, or scrap something if it didn't work.
  10. 50% off sale ends tomorrow. The new release has an early version of the documentation and contains projects for Visual Studio 2010 and 2012.
  11.   It's a C++ engine that exposes SNES like features as classes. You don't have to deal with any of the 2D on 3D hardware 'technical' stuff. You develop a game as if you were targeting hardware with a tile mapped display, sprites, input, sound, and music. And, unlike most of the 2D engine, there is no need to create optimized texture atlases.   It's about as close to 'pure game development' as I can think of, as you never have to worry about the underlying hardware.
  12. The Super Player Game Engine, has been released. There is a demo game with source code available.  It's available for 50% off ($14.95), for the Ludum Dare competition, until Dec. 20th 2013.   http://www.superplay.info  
  13. Finishing up Super Play, my SNES inspired game engine. http://www.superplay.info
  14. Finishing up Super Play, my SNES inspired game engine.