• Advertisement

kushinn landoky

Member
  • Content count

    1
  • Joined

  • Last visited

Community Reputation

115 Neutral

About kushinn landoky

  • Rank
    Newbie
  1. PC vs Console

    Ugh... I hate how this myth persists... in most cases the console and PC games are developed at precisely the same time from the same code base and the same basic asset sets - there is no 'porting' of code going on. In our games ~95% of the code base is the same between platforms and at any point during development you could compile the game for the target platform and it would run. If the UI is 'bad' it is because it was a design choice made which probably had very little to do with what platforms were being targeted. I put up with this myth/misunderstanding on gamer forums, because frankly those guys are laughably clueless at times, but it shouldn't be something which persists on a development forum...   In some cases, it's only false on a technicality. In my experiences, our engines were cross platform, so the game would run on PC/360/PS3 pretty much the same throughout the entire development cycle. Even when we were making a 360-only game, or a Wii-only game, most of the staff would be developing on the PC -- so it's false in that regard, the game is developed on the PC. However, our publisher usually didn't want a PC version at all, so that build wasn't released, or they would want the PC version 12 months later (apparently to avoid PC piracy impacting console sales). In that latter case, the publisher would also want this late PC release as cheap as possible, so one person would be assigned to dig up the 12-month old code and assets, and get it presentable. A small team would then work with QA to fix any (severe) PC-specific bugs that were reported, and to integrate platform APIs, like GFWL or Steamworks. The smallest amount of money possible would be spent getting this PC build out the door, which meant: * no extra graphical options, even though we could've easily added higher quality settings. * no GUI menu for customizing controls. You play with a 360 pad, use our keyboard layout, or hack our config files. * no tweaks to the in-game UI to better suit keyboard/mouse controls, rather than one optimized for game-pads. * a poor online experience with a quickly ported GFWL matchmaking/friend system, even though every gamer despises GFWL. * no support for modding of files, even though it would've been easy to release the toolset and despite the quite large group of fans waiting to create mods for us (they'd already set up a website/forum to share their mods) to extend the life of our product... * and once: frame-limiting the game to 30Hz (which is what the consoles ran at), because the AI performed differently at other frame rates. So despite them not technically being "ported" to the PC, I have still worked on enough "cheap PC ports"...     this voice in my heart
  2. Let's Make: BattleGame! [Part 1 - Classes]

    Boy, I have carefully read your codes, and found a lot of bad problem. Although does not cause any errors, I would suggest that you read more books about the C++ programming language . Game development is not easy, but I hope you persist. Then, I have listed some problems: 1.std::string //using a reference when you get/set it from external (Note: copy constructors) 2.don't add "using namespace std" directly in your code, in especial the C++ header files; 3.what's the difference between private, protected, and public. Good Luck!
  • Advertisement