LÖVE

Today's update:

Well thanks to some help here on the forum I managed to fix the bug in the namepicker library. This now opens the door to generating all of the emails, letters ect in game. Also it enables me to finish the NPC/character generation part of the game.

Some interesting things to think about even a fairly conservative world if you actually keep all the generated emails/mails between each NPC that soon becomes a huge amount of text data. Consider a small scale simulation. Each NPC has around 3 emails. Now you have 5,000 NPCs. that's 15,000 emails. at 50k per mail that's going to clock in at around 730mb.. Also each person receiving a piece of mail had to have a sender. So you have another ID to link to a document when that document is generated and keep track of. Ideally on that persons account in the out folder you would have a copy of that document.

So here is my solution. You give the illusion of the physical presence of these emails/letters. But really all you have is a table of bools linked to an NPC ID. the program looks at the table. if its TRUE then it goes ahead and generates the required email/letter using a template and the name linked to the NPC id. This will significantly reduce the amount of space needed and enable much larger simulations to be performed. With this I am limited by the ram on the system.

One interesting thing you can do is when you move away from static physical text assets for NPCs you can alter the asset base on the fly dependant on game choices/quests ect.

The Deus Ex human revolution game writer had a weekend by herself to write the majority of the emails that you see in the game. So I knew that to get a fairly impressive asset set together was possible for one person to do on a limited time scale. With the use of templates also you can greatly expand the realistic "fluf" that most accounts are going to have inside them. That was one of the disadvantages with the human revolution game. Every email was either funny or relevant to the game. Everything had a purpose to your quest. They way I want to do things, it would be like just looking at a normal persons email. - Unless you knew what you were looking for it would be like a needle in a haystack. Therefore throwing a bunch of templates at an account that fits a profile makes sense. You can add in quest template communications as needed just as a regular template. But the key is its not the only thing in the box besides a Nigerian scam letter. (Plan to have a bunch of these also.)

So you read this far - congratulations. Today's objective is beginning work on the document template library (Dolos). There managed to come up with a name for one of the libraries of the program before the actual program itself...

Evening update:

Well due to a fairly brutal headache not much got done today. But despite this managed to get sti working, can't tell you how happy I was to see final fantasy adventure map load on the screen lol.

Today's update:

Due to lack of documentation/tutorials/books it comes down to transferring attention to parts of the game that I have a shot of actually completing and getting them done and going back to the unclear stuff later.

What is the userbase for Love? Seems pretty small. I mean you look at something like cocos2d and you have hundreds of books, many more tutorials - same with a few other of the frameworks Why is there so little out there to learn with that is current? I see lots of tech demos, ect but very little in the way of tutorials, guides, documentation going on. Have you tried to use the wiki lately? To do anything...

Was there not some conversation at some point "Hmmm look does nobody see it as a problem that the one book written about the framework is 3 years out of date, is no longer maintained - with hardly any functional tutorials that produce an actual game?" Most tutorials you see are hopelessly trivial or broken. Compared to other frameworks support there is next to nothing for love.

So somehow users are just going from zero to hero with out of date documentation, next to no current tutorials and no books. How is this happening?

Where are the examples that people are holding up as technical achievements - fully featured games. Not technical demos.

Where are the good projects to study? How would you even know one if you saw it as a beginner anyway? its a sea of technical demos and trivial games. You don't want to write a 2600 type game then its pretty bleak.

Stuff that is on me as a user to implement that you get in the box with other frameworks - A director function. (gamestate). That is ok. can use the 3rd party library hump.gamestate. Always wondered why this was not part of the core functionality of a game framework. If a framework is for making games would it not follow you would include a way to manage state?

Second scene transitions - again not implemented by the core library in away way I can see. Possible with things like hump.camera and a few other 3rd party libraries working together with a timer (hump.timer or cron). Again comes as a standard part of the library in most game frameworks. In Love you have to do this yourself... Good luck finding tutorials on that also.

So pretty much everything that you would need to implement a non-trivial game is going to be on you to implement this in love.

So I am back to the "Director" system a.k.a hump.gamestate. and working on the overall program structure. I think an achievable goal for today is to get the title screens working, with a graphics menu that links to the earlier work I did with the character stat help menu.

Seriously 1 book..

Anyway enough bitching, time for some proactive work.

Lets take a look at the various target desktop screen resolutions - not all of them but enough to show part of the problem our little program is going to have selecting a happy compromise.
The various boxes list everything from cga, the 8 and 16 bit consoles and a few of the 32 bit.., plus our more modern desktop PC resolutions (these are the larger boxes you can see on the outside.)

Its important to consider because now with such a wide rage of devices that the program could be displayed on. Especially when you factor in tablets and mobiles you have to at least consider how your program is going to work.

Also you have issues on how you handle resolution, are you going to stick rigidly to a screen resolution irrespective of screen size? or would you let users resize the screen as they like? it might affect your art style choices.

So unless we are 100% sure that our program is only going to be displayed on 16:9 factor huge screens. We are going to have to accept some compromises in wasted screen space and go with a aspect ratio all displays can handle 4:3 (your get the bars at the left and the right.)
or we go with a 16:9 ratio and have the black bars top and bottom. The choice is yours. But you better make it quick as next comes the menu design...

I figure I will go for 4:3 - mostly because I am old...

So here's the plan, lets have a main screen. You then have three choices. continue, new game or settings. Already we need 4 scenes to handle these 3 menu choices (plus the main menu).

For now lets just put a place-holder up consisting of a png file. Later were think about making this a bit less brittle and a little more fancy. But just to get something up there and on the screen.
Here we have the continue screen, as with the main screen for now its just a flat png place-holder. Later were actually implement the load state.

Next up is our second choice - NEW GAME. As this begins a new game your need to generate a new character the first step in most traditional console games was selecting a name. (with RPGs anyway.)
Like the rest of these menus, its just a flat PNG for the moment. The important thing is we got something on the screen that reminds us what the menu does. As we go we can implement the functionality that it shows.

In consoles you have this interface because most didn't have a keyboard and data entry was dependant on a joystick/game pad.
Now with the program being able to be run on many different target systems, we need to make sure that this interface can work for all users. Some might not have access to a joystick or game pad. So one thing to make sure is that mouse input works for this interface as well as enable keyboard input. (and i guess eventually touch.)
The last main menu choice is SETTINGS this enables the user to modify the standard game configuration to better suit there platform.

At this stage I now plug these png's into my skeleton project with hump.gamestate. and taadaaa.. gotta basic menu.

Next is to go back and get some placeholders for the submenu's and plug those into the skeleton.

The settings sub menus are as follows, The behaviour is you can access sub menus or escape to go back up a level of the menu structure. As it stands these screens are just pngs, but eventually they will have there own functionality. At this stage its just important to get the structure in place and the menu system working.

All the menus currently have keyboard support. Next will be to get mouse support, then joystick, gamepad..
Here is the video settings submenu. And here is the sound settings submenu Finally the control settings submenu In total it will require a further eleven screens to cover all the options here. You can see even with a fairly basic menu system it soon becomes pretty extensive. You can see why its important to just get the basic structure nailed first before extensive polishing.

Here's where a can of worms is going to open up - remapping controls. I figure a command pattern should be perfect for this. I have examples of it in C++ but I have yet to find a lua example of this. That's something for later anyway. But for whatever reason a player should be able to re-assign buttons/keys as they like.

Tonight's update:

First of the control sub menu - sub menu's. Eventually your be able to completely redefine all of the keys. Assign macros. For now you get a image place-holder and basic menu navigation.
Today's Update:

Here is the gamepad menu screen prototype.
Tip: its better to integrate screens into the project as soon as they are completed rather than doing them in batches. Something to be said for seeing your work functioning as part of the programming ASAP. I find it helps stop boredom and switches up your tasks between messing with inkscape/gimp and doing some minor coding/testing.

This prototyping also while not the prettiest interface still serves as a test system during development. Its more useful than having one beautiful menu screen and a big bunch of nothing to work with lol.

Anyway - plan today is to continue making the prototype menus for the game and plugging them into the skeleton of the project. Plan for today is to complete the main menu and sub menu screens. once they are in place. plug in the main game screens, and merge with the previous work I did on the character stats menu.

Here is my rather nasty mouse screen.

Here is the slightly better looking joystick page.
Jumped to the video submenu as i think of how to do the touch screen.
So now only 5 screens left to complete then we have a working skeleton for a project.

Today's update:

Spent most of yesterday getting assets together for an experiment after playing dark-lands again had another idea how to handle the towns/cities in game art style wise.

Figure am going to crack on and complete the menus. start thinking about the transition library.

Tonight's update:

Have cheatcode library working in the project. This is a very useful library especially in the development of games. I can break the game logic/rules to test certain situations and speed up testing of parts of the game world. Just being able to teleport around the game world is a big plus as I don't have to use the game transport system. Same as I am now able to manipulate character statistics on the fly when needed and not have them polluting the regular game code.

Today's update:

Tip:To avoid some needless/pointless frustration. You start the package zerobrane-studio from the terminal with zbstudio.
It is Ok program. would be useful for debugging. but for day to day stuff I will just stick to joe and the terminal.

Today's task continue combining all my previous demos/work into the new project.

Tonight's update:

Considerable progress was made - most of the libraries I will be using now are functioning within the project.
Some progress was made on the game mechanics. With the help of the Zimpel library I can now encode text data and decode it within the game. This is great for puzzles and handling situations where a player does not have the correct password/ID code or could not hack a terminal or device.

Am thinking of using this to encode the data files for the game. While its trivial to figure out what's going on to a casual this would be enough to stop them.

Early morning (lol):

In the words of Hannibal Smith - "I love it when a plan comes together."

This was a target since I joined the forum, https://www.love2d.org/forums/viewtopic.php?f=4&t=82424 so <smugmode>
Finally figured out the shine library and how to get it working with transitions between gamestates (I know - I am a slow learner.)

Stay tuned for a transition library in the next week or so...
</smugmode>

Today's update:

Had a nice morning editing art assets, then got cracking with the coding.

Have spent the day merging the assets and libraries from the previous projects into the current one. And also adding a few libraries I always wanted to get in the game (lue) as much as possible I would like to leverage what's available for 2d games without opengl 3. So I am trying to get all of the libraries working together and the skeleton program working now. Everything touch would has been pretty straight forward surprisingly. All of the graphics and sound libraries are loaded, same with the serialize. only libraries that need to be added are the physics/collision libraries, AI, networking, and file system (optional).

Tomorrows task will be finishing adding in the old work I did on the character statistics, the input functions, the icon printer ect all that good stuff from before. Mostly its behind the scenes stuff like writing the SUIT code for each scene so there is mouse support for the new scenes. making sure that the gamepad will work with them also and the icons. So I don't expect a whole bunch of new features for the next couple of days its just going to be a case of me getting the old stuff to work together as a whole.

Any suggestions on what network library to go with?

Today's update:

So just got the name generator library plugged in and working with the new project. As I said last night this day is going to be spent building functionality into stuff I already did. So getting SUIT working for each scene where its applicable. Music from TEsound is now working throughout all of the project not just the character stats help menus. Getting the sound control to work on all of the scenes is another task for today. Then if I get time. getting the input icons. (but that last one is a stretch goal.) If I get to bored will get a few more art assets done.

Tonight's update:

Well not exactly a super productive day, still managed to get sound configuration working you can now... raise the volume and lower the volume, or mute as you wish. Managed to get a few art assets done today also. So really only sound was finished today. But still progress is progress right..