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.

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