Hello,

To summarize what I said in the introduction post:

I am a phd student and my work is in programming languages, and I want to make a game to flex some muscles in the down time between working on my research this winter break.

I like working on collaborative experiences so I want to make a multiplayer game with libGDX as my front end and elixir as my back end. I really like the idea of asynchronous + asymmetric gameplay. Something with deliberate tiers of involvement. For example: my elixir backend persists state for concurrent actors (players, game AI, entities, etc), my main libGDX project holds the code to build a generic client side representation, and each application interacts with it. It would be neat if some players played a Neko Atsume style game where the source material for it is the same world other people are playing an rpg in. Or if someone linked a persistent world between that fall out mobile game and their fall out first-person world.

Do I have any ideas for what game I would actually make about life in space? Not really.. But my wife is very creative (and can help me) and I am thinking I might actually be more successful letting the game tell me what it wants to be like, rather than the other way around.

I am going to be doing my development in this repository:

https://github.com/mpahrens/hereland_farland

and will hopefully be putting up screenshots and design documents asap.

End of night 1 post

• Made a default libGDX project
• Made a default elixir project
• BrainStormed with the wife

Didn't make direct progress on anything in particular but looked at some art, and did some pixel sketches in Aseprite. Then followed Xoppa's importing 3D model tutorials in libGDX just to see how hard it would be to get started with 3D art. (to be honest, sculpting something in 3D and making something look nice in pixel art, and poking at lines in vector art really all have a similar barrier to entry.).

Learned that Sculptris, while very easy to use and is fun to play with, does not export .mtl files and so it was too much trouble to use it as my primary 3D modeling tool. I miss milkshape (even though I didn't like it) and might hammer a nail with a machine gun by using blender instead (again). We'll see.

Day 3. Spent today cleaning the house and preparing for the work week tomorrow. Might start a Kanban or some other type of scrum board to organize my thoughts soon. For now, the immediate todo is to find a small mechanic and implement a rudimentary version of it. It is always easier than staring at a 'blank canvas' so to speak.

Day 4 (after taking a day or two for the wife's Bday and some cleaning)

Did some story boarding and boiled the game I want to make down to one I can make in a month by limiting myself to a handful of features and figuring out what needs to be done before what. I'll probably post some of those on my twitter account but short version:

Probably going to use Joren Six's TarsosDSP library to implement weird music features. Primary game mechanism is going to be: Explore alien worlds and snap samples (audio and video) from those worlds to make cool instruments and songs and be a hit on the intergalactic charts.

Played around with TarsosDSP library after getting back from X-mas eve dinner with family. Rewrote some of the base classes from the synth example to be non-blocking and let me mutate state (the functional programmer in me is saddened by this. Might think about a Kotlin Actor model for the music synthesis of it gets tooo messy). Realized a cool "game flow" for this project:

1. You go to a planet.
2. Associated with game entities (wind, rain, bunnies, etc) are a tuple of visuals and sound.
3. Visuals are made up of patterns on sprites; Sound is made up of a sequence of Tarsos AudioProcessor chains with some params.
4. You wait around and at some point sample the sounds playing at a particular time (pokemon snap but for music haha)
5. You take the sample back, do some alchemy on it
6. put it in an instrument
   1. an instrument has at least the properties of turning the sample on and off, and then building one up lets you control parameters (real time modulation) or mutate AudioProcessor and visual objects (before hand modulation)
7. Then you can use the instrument in songs.

Sidenote: I am definitely drafting a declarative markup for describing these worlds, and making that the "source" of the sample snaps. That way I can push anything I want server side and store it easily, knowing that the java game implementation is literally just an interpretter and not holding any logic against me. I can see these AudioProcessor object chains getting out of hand really fast!

So, in order to do the list in last night's post, I have been thinking about where to start so that I'm not just building small tech demos and then dismantling them back into their pieces al a "lego coding".

I think I am going to start but trying to get 2 things done this weekend:

an editor that eats json specs for entities and demos them so I can prototype them quickly and 1 'world' a player (cube placeholder art lol) can navigate around in. That seems doable and lets me not stress about my art skills just yet. It also will let me get closer to making all the design decisions about what entities of a world should 'have'. I am thinking of being lazy to start and maybe I'll like it. Where an entity is just a collection of: sprite outline/base, vis. pattern (color), AudioProcessors, AudioBehavior, MovementBehavior, AppearanceBehavior.

And then your sampler just picks up the pattern and processors. The behaviors are essentially the tweaks to the params over time as well as "when should an entity appear/disappear" to add some artificial scarcity.

Hopefully this can fit in a weekend with only a few hours given to it. We'll see.

Started on the editor, and noticed a latency problem between pressing a key (WASD) and a musical event occuring (changing pitch on a sine wav generator)

So I made my own version of the TarsosDSP AudioPlayer that uses Gdx.audio instead of javax.sound or whatever.

Also made a new audio processor, Hard Limiter, which now may be unnecessary but is still a nice thing to have and put on the end of processing so no one gets peak artifacts blasting their eardrums

Downloaded Spriter today, again. I was a KS backer a long time ago (2012? 2013?) but never made enough art to warrant the use. Also, my classmate who made game stuff with me backed libGDX's spine and I have a copy of that as well.. So I am currently weighing the pros and cons of using one over the other.

Partial lists:

Pros of Spriter:

• I know it

• I don't know how to make its system work in libGDX other than following some help here: https://github.com/Trixt0r/spriter

Pros of Spine:

• Works well with LibGDX out of the box
• Very sleek looking / full featured

Cons of Spine:

• Crashes CONSTANTLY on my mac. D:

Accidentally slept through New Years.. Oops. But did go into work in between the holidays and work on my research. I have a more concrete schedule for everything starting Saturday. So we'll see how it goes! 2 hr homework + 6 hrs Research + 2 hrs game.