I've reimplemented the source information in mybacklog using a dictionary for most of the data. Each item points to the class that is used for dealing with special cases with that item. It looks something like this:
Note that both humble and none (none is a standin for "I don't remember/care where I bought/downloaded this game but it's on my hard drive") point to the same class. To the user they DO look different, and in fact the client knows how to import humble games, however from a data perspective they both act the same. If the user wants to record a source which I hadn't thought of (for instance, I've only created snes, gba, and n64 emulator support, so what if someone wants to add a playstation game and emulator?) they will just choose the closest "base" source to base it on and add the new name. I probably wont make a real interface for this in the first version...
Additional. These sources can make use of some data stored in the local storage. (The local storage is unique to every computer mybacklog is installed to, while the game database is intended to be shared across devices). In the case of EmulatorSource, they look in the local storage to find the command line to run in order to launch a rom for that specific source. So "snes" is going to look for local["snes"]["command"]. This way you can configure your emulators on a device once, but share information about playing a particular rom.
I think if this game is going to get made I'm going to have to switch back to HaxeFlixel. I'm liking Luxe and will continue to use it in the future, but I took some time today trying to understand Luxe States and Scenes. My end result was something that works a lot like HaxeFlixel does. I'm still continuing Luxe development and think it might be the future engine of choice, but I don't have time to complete the game and learn a new engine at the same time.
Heck, I might not have time to complete the game even without the new engine...
When finished, I'm going to shrink this down 50% then blow it back up to twice its normal size using nearest neighbor to give it a nice pixely look that will match the sprites I've been making.
Worked a lot today on my #PDJam submission, and also planned few things for my other 3D puzzle game on Unity.
About my #PDJam game:
- Choices are divided in 3 categories: sane, disturbing, and insane -- with "Madness points" assigned to each of them
- Scale: madness increases each time you make a choice; until a point where sane choices won't be available
- Small scenes: just 2 choices per scene until there's a consequence based on your previous choices
- You can play these scenes in any order you want; but the order has an impact (as your madness increases, if you play a scene first, you'll be "madder" in the next scene)
- Closing scene: you'll see the results of all your choices... with some narrative twist
- Contamination: your text evolves as your madness increases
What needs to be done:
- Actual writing -- I'm almost there with the architecture and system
- "Closing scene" components -- working a bit on the twist // contamination
Hey streakers! I've managed to improve my AI behaviour a lot. Enemies now follow the player and investigate last player's position when contact is lost. They also react to being shot or pushed and brake when needed. Besides behaviour I have also heavily reworked whole behaviour tree structure and internal mechanisms which means more stable AI.
Wanted to draw a bit but drivers problems. Then need to reinstall them and too lazy to reboot my computer. XD
So I drew some – really – basic stuff to prototype some little 2D games.
As I don't have too much time I will add more content later, and after uploading the file I see that it's a bit crappy. =/