Save 37% off PRO during our Black Friday Sale! »

Making of CuBeat, Programming-wise

0723b829421d651f25991ffb12ff0b55?s=47 IGDSHARE
April 11, 2014

Making of CuBeat, Programming-wise

It basically is an overview of the libs and tools used, with explanation about some more "re-usable" parts and also about what we (probably) did awfully wrong.

0723b829421d651f25991ffb12ff0b55?s=128

IGDSHARE

April 11, 2014
Tweet

Transcript

  1. 2014.04.11 @ OSDC.tw By Johnson Lin @cubeatgame || www.facebook.com/cubeatgame The

    Making of Programming-wise
  2. About me Johnson Lin Programmer & Indie Game igdshare.org &

    IGDA Taiwan ( igda.tw ) archilife.org & Indie game contests scholarship ( 祐生研究基金會 )
  3. Overview Libraries Used (with some in-house ones) - especially: Easing

    Functions & Custom Dictionary Development Issues (that I think is interesting) - AI design & impl - Why game programming is messy - Cross-platform? All (?) the Mistakes (??)
  4. Let's demo first.

  5. Overview Libraries Used (with some in-house ones) - especially: Easing

    Functions & Custom Dictionary Development Issues (that I think is interesting) - AI design & impl - Why game programming is messy - Cross-platform? All (?) the Mistakes (??)
  6. Libs & tools https://github.com/godfat/cubeat/

  7. Libs & tools gcc 4.6 ruby 1.8-1.9 CMake code::Blocks (on

    Win) https://github.com/godfat/cubeat/
  8. Libs & tools Irrlicht 1.7 (custom) Boost 1.48 Freetype 2.3.x

    LuaJIT2 Ogg/Vorbis ALmixer ManyMouse Loki … (any many other things no longer used) gcc 4.6 ruby 1.8-1.9 CMake code::Blocks (on Win) https://github.com/godfat/cubeat/
  9. Easing Equations Lala (Demo)

  10. Easing Equations obj->tween<Eq, Accessor> (start, end, time, loop, callback, delay);

  11. Easing Equations obj->tween<Eq, Accessor> (start, end, time, loop, callback, delay);

    AnimatorParam<Eq, Accessor> anim, anim2; anim.start(s).end(e).time(t); anim2.start(s2).end(e2).time(t2);
  12. Easing Equations obj->tween<Eq, Accessor> (start, end, time, loop, callback, delay);

    AnimatorParam<Eq, Accessor> anim, anim2; anim.start(s).end(e).time(t); anim2.start(s2).end(e2).time(t2); obj->queue(anim).tween(anim2);
  13. Easing Equations obj->tween<Eq, Accessor> (start, end, time, loop, callback, delay);

    AnimatorParam<Eq, Accessor> anim, anim2; anim.start(s).end(e).time(t); anim2.start(s2).end(e2).time(t2); obj->queue(anim).tween(anim2); * cubeat-core/include/EasingEquations.hpp * cubeat-core/include/Accessors.hpp * cubeat-core/include/view/Object.hpp * cubeat-core/include/view/detail/CustomAnimator.hpp
  14. Custom "dictionary" 'key1': { 'somelist': [-1.1, [14, 15, [3]], 6,

    13], 1: '234', 'val': 5 }
  15. Custom "dictionary" 'key1': { 'somelist': [-1.1, [14, 15, [3]], 6,

    13], 1: '234', 'val': 5 } #comment #number => 1, -1, 1.0, -1.0, 0xfe, -0xfd. #string => 'string', ThisIsAString_Too #map => { ... } #vector => [ ... ] #delim => ,(comma) :(colon)
  16. Custom "dictionary" map.V("stafflist").M(1).S("phone");

  17. Custom "dictionary" map.V("stafflist").M(1).S("phone"); implies => 'stafflist': [ ... , {

    'phone' : 'something', ... }, ... ]
  18. Custom "dictionary" map.V("stafflist").M(1).S("phone"); implies => 'stafflist': [ ... , {

    'phone' : 'something', ... }, ... ] map = map_any::construct( from_str ); vec = vector_any::construct( from_str );
  19. Custom "dictionary" Uses: tr1::unordered_map & std::vector + boost.any boost.algorithm boost.lexical_cast

  20. Custom "dictionary" Uses: tr1::unordered_map & std::vector + boost.any boost.algorithm boost.lexical_cast

    Have often-used std container interfaces
  21. Custom "dictionary" Uses: tr1::unordered_map & std::vector + boost.any boost.algorithm boost.lexical_cast

    Have often-used std container interfaces Very ugly usage of exception when serializing
  22. Custom "dictionary" Uses: tr1::unordered_map & std::vector + boost.any boost.algorithm boost.lexical_cast

    Have often-used std container interfaces Very ugly usage of exception when serializing * cubeat-core/include/utils/dictionary.hpp * cubeat-core/src/utils/dictionary.cpp
  23. Overview Libraries Used (with some in-house ones) - especially: Easing

    Functions & Custom Dictionary Development Issues (that I think is interesting) - AI design & impl - Why game programming is messy - Cross-platform? All (?) the Mistakes (??)
  24. AI Design & Impl Problems Started asking around on ptt.cc

    (Prob_Solve) in 2007.
  25. AI Design & Impl Problems Started asking around on ptt.cc

    (Prob_Solve) in 2007. Dunno how to impl AI strategy for building chains.
  26. AI Design & Impl Problems Started asking around on ptt.cc

    (Prob_Solve) in 2007. Dunno how to impl AI strategy for building chains. Research some kind of patterns? Neural network?? Reinforcement learning??? Genetic algorithm????
  27. AI Design & Impl Problems Started asking around on ptt.cc

    (Prob_Solve) in 2007. Dunno how to impl AI strategy for building chains. Research some kind of patterns? Neural network?? Reinforcement learning??? Genetic algorithm????
  28. AI Design & Impl Problems http://kamoland.com/wiki/wiki.cgi?RensaWiki

  29. AI Design & Impl Problems http://kamoland.com/wiki/wiki.cgi?RensaWiki Puyopuyo "Rensa" walkthrough site

    with AI programming competiton !!! ...
  30. AI Design & Impl Problems http://kamoland.com/wiki/wiki.cgi?RensaWiki Puyopuyo "Rensa" walkthrough site

    with AI programming competiton !!! ... And basically, the strongest strategy is just brute-force.
  31. AI Design & Impl Problems http://kamoland.com/wiki/wiki.cgi?RensaWiki

  32. AI Design & Impl Problems So, let players try the

    AI.
  33. AI Design & Impl Problems So, let players try the

    AI.
  34. AI Design & Impl Problems So, let players try the

    AI.
  35. AI Design & Impl Problems So, let players try the

    AI. Few people could beat EASY.
  36. AI Design & Impl Problems So, let players try the

    AI. Few people could beat EASY. * made AI even slower, too boring - player learns nothing
  37. AI Design & Impl Problems So, let players try the

    AI. Few people could beat EASY. * made AI even slower, too boring - player learns nothing * occasional "critical hit" - randomness problem - you don't want player get defeated randomly - computer simulated "hand-shaking" - had to make pace feel right to new player
  38. AI Design & Impl Problems

  39. AI Design & Impl Problems FACT 1 Easy AI is

    the HARDEST one to get right.
  40. AI Design & Impl Problems FACT 1 Easy AI is

    the HARDEST one to get right. FACT 2 Good enough is good enough.
  41. Why Game Programming is Messy (Demo)

  42. Why Game Programming is Messy A. Impossible to know what

    will actually work
  43. Why Game Programming is Messy A. Impossible to know what

    will actually work B. Many things are coupled by nature/design, nothing to do with how you code it
  44. Why Game Programming is Messy A. Impossible to know what

    will actually work B. Many things are coupled by nature/design, nothing to do with how you code it A+B = layers of workarounds, unexpected complexity & bugs/crashes hard to keep code clean
  45. Cross-Platform meaning? C/C++ is a portable language.

  46. Cross-Platform meaning? C/C++ is a portable language. But use cross-platform

    libs & tools & getting all the code to compile is only the beginning.
  47. Cross-Platform meaning? C/C++ is a portable language. But use cross-platform

    libs & tools & getting all the code to compile is only the beginning. Some libraries may not be maintained well.
  48. Cross-Platform meaning? Deployment & UX adjustments is PITA.

  49. Cross-Platform meaning? Deployment & UX adjustments is PITA. - OSX

    *.app formats
  50. Cross-Platform meaning? Deployment & UX adjustments is PITA. - OSX

    *.app formats - ManyMouse (old) on Linux
  51. Cross-Platform meaning? Deployment & UX adjustments is PITA. - OSX

    *.app formats - ManyMouse (old) on Linux - Android apk filesystem restrictions - etc
  52. Cross-Platform meaning? Deployment & UX adjustments is PITA. - OSX

    *.app formats - ManyMouse (old) on Linux - Android apk filesystem restrictions - etc May be better to focus on 1 platform at a time, but keep code portability at all cost.
  53. Overview Libraries Used (with some in-house ones) - especially: Easing

    Functions & Custom Dictionary Development Issues (that I think is interesting) - AI design & impl - Why game programming is messy - Cross-platform? All (?) the Mistakes (??)
  54. All the Mistakes Questionable/Bogus stuff & decisions we had "MVP"

    Presenter View Model
  55. All the Mistakes Questionable/Bogus stuff & decisions we had "MVP"

    Presenter View Model Presenter bind view's method to model's function object
  56. All the Mistakes Questionable/Bogus stuff & decisions we had Well..

    why not
  57. All the Mistakes Questionable/Bogus stuff & decisions we had Well..

    why not View Model
  58. All the Mistakes Questionable/Bogus stuff & decisions we had Template

    setter & getter for view objects: obj->set<Pos2D>(vec2(100, 200)).set<Alpha>(128);
  59. All the Mistakes Questionable/Bogus stuff & decisions we had Template

    setter & getter for view objects: obj->set<Pos2D>(vec2(100, 200)).set<Alpha>(128); And because it looks cool: obj->onPress(button) = bind(function, ...);
  60. All the Mistakes Questionable/Bogus stuff & decisions we had Pre-processed

    C++ source/header
  61. All the Mistakes Questionable/Bogus stuff & decisions we had Pre-processed

    C++ source/header Using eruby (erb-like) to proc. embedded ruby
  62. All the Mistakes Questionable/Bogus stuff & decisions we had Pre-processed

    C++ source/header Using eruby (erb-like) to proc. embedded ruby Model.cpp.eruby -> preprocess -> Model.cpp
  63. All the Mistakes Questionable/Bogus stuff & decisions we had Pre-processed

    C++ source/header Using eruby (erb-like) to proc. embedded ruby Model.cpp.eruby -> preprocess -> Model.cpp Debug hooks Auto #ifndef #define #endif block for headers Generate property getter/setters. Expand Boost.object_pool signatures.
  64. All the Mistakes Questionable/Bogus stuff & decisions we had "Multiple-View

    System"
  65. All the Mistakes Questionable/Bogus stuff & decisions we had "Multiple-View

    System" There was a time when 2D/3D switches seemed cool to us.
  66. All the Mistakes Questionable/Bogus stuff & decisions we had "Multiple-View

    System" There was a time when 2D/3D switches seemed cool to us. And we also thought maybe we need multiple view presentations.
  67. All the Mistakes Questionable/Bogus stuff & decisions we had

  68. All the Mistakes Questionable/Bogus stuff & decisions we had

  69. All the Mistakes Questionable/Bogus stuff & decisions we had "Multiple-View

    System" void go_exploding(int color_id){ BOOST_FOREACH(pViewBase& view, view_slaves_){ if(view) view->go_exploding(color_id); } view_master_->go_exploding(color_id); }
  70. All the Mistakes Questionable/Bogus stuff & decisions we had "Multiple-View

    System" void go_exploding(int color_id){ BOOST_FOREACH(pViewBase& view, view_slaves_){ if(view) view->go_exploding(color_id); } view_master_->go_exploding(color_id); } It hasn't been utilitzed. ....Yet.
  71. All the Mistakes Questionable/Bogus stuff & decisions we had

  72. All the Mistakes Questionable/Bogus stuff & decisions we had Read

    the book already even before we started, clearly that was not enough.
  73. All the Mistakes Questionable/Bogus stuff & decisions we had Read

    the book already even before we started, clearly that was not enough. The last 10% need 90% time,
  74. All the Mistakes Questionable/Bogus stuff & decisions we had Read

    the book already even before we started, clearly that was not enough. The last 10% need 90% time, and it is recursively true.
  75. All the Mistakes Questionable/Bogus stuff & decisions we had Biggest

    Mistake:
  76. All the Mistakes Questionable/Bogus stuff & decisions we had Biggest

    Mistake: The game isn't out yet.
  77. All the Mistakes Questionable/Bogus stuff & decisions we had Biggest

    Mistake: The game isn't out yet. (hopefully we can get it done before Spring is out, but Spring includes May... hmmm)
  78. Thank you for listening! Q & A arch.jslin@gmail.com gplus.to/jslin johnson_lin

    @ plurk