On 9 January 2014 04:26, deadalnix <[email protected]> wrote: > Mandatory bikeshedding : the name is ungooglable. I do think that > this is a problem. >
Make some suggestions? I'm not really stressed, although this name is a brand that resonates with the GH/RB enthusiast community since back in the GH1/2 days. People know it, and I see no real reason to abandon it. People don't google the name of something they don't know exists... and anyone who does know it exists can easily write 'game' after the search term. Also, can you give a brief overview of the architecture you have > in mind, and what are the things that can be worked on in the > current state of affairs ? > Well, in the interest of producing a project that's at least familiar to the gamedev community at large, and therefore useful as a reference or an inspiration for other gamedevs to consider using D in their projects, I tend to think taking a typical (although D flavoured?) OO approach makes sense. Non-D coders should feel more-or-less immediately comfortable. But a critically important part of this process, at least for me, and the main reason I put it to the community here for contribution, is because I'd like to explore gamedev from a D-centric perspective. I have decades of habitual baggage from C/C++, so I need other people to keep me in check, and offer suggestions that I might have dismissed or overlooked... or rather, demonstrate via their contributions to the project ;) So it's a balance, I don't want to get too experimental with D paradigms, it should remain practical, and it's important that it appears realistic to non-D gamedevs as a point of reference. There are lots of parts that can be developed in isolation. For instance, to do vocal or 'pro-guitar' modes, a DSP which can parse an audio stream into a midi sequence with extremely low latency is required... this would be a very interesting challenge for anyone interested in signal analysis (I can wing it, but I'm not an expert by any measure). Other abstract elements like a UI system... I don't know of any UI libs for D which support custom rendering backends. This UI will be a little special, since it would require the concept of having multiple points of 'focus' where many players can interact with the UI simultaneously while choosing their play options and stuff. I also think being able to theme/script the UI is important, so expressing layout with a user-friendly XML, and integrating something like Lua for sequencing the flow of menu's would make the game user-theme-able. That's proven to be very successful from my StepMania days. The modder community really gets involved in theming things, and that's where the best art/design comes from (there's rarely good artists or visual designers hanging out on Github!). If you want the game to look really good without any paid artists, then powerful user-theming support is a must! :) And there's heaps more stuff too. Profile management (Oauth? Google/FaceBook? Open Feint? Platform-centric profile managers?), a web-service that offers a downloadable song database which users can browse in-game, reverse engineering to parse data from the existing games (I have some existing code to this end)... can all be started in relative isolation for the time being. I started populating the issue tracker as I think of stuff, you're welcome to add things too. I'd like to hear about the sorts of things people are interested in working on. With that, it might be easier to create some sort of plan of attack based in the skills/interests available. I can fill in any gaps, but I only have so much spare time myself :)
