I is interesting. Even if I announced previous week as Gameplay, most of closed tickets were pure technical. - bugfixes, GUI updates and so in.
Our finished list:
1. Four more clothing sprites.
2. Global map is no longer painful to use. ^_^
3. A portion of nasty bugs were cleared.
4. Config.cfg got more features.
5. Couple of GUI tweaks.
6. Creatures drop specified corpses.
For the next week we start serialization and client/server routines. They are required for many and maby features (for example quests), but first "feature" would be game saving.
Procedurally generated roguelike rpg set in the underground world waking up after a major catastrophe.
Jul 11, 2015
Jul 7, 2015
Screenshot from old times!
Ha! Vadim found build of old Fallen. Well. I think we made some progress since then.
Upcoming 'Technical' week (database)
As I wrote on our Trello board, we have two cycles of development: Gameplay weeks and Technical week.
While gameplay weeks take 3 of 4 weeks in a month, technical week takes one. 3:1 is good ration for technical vs gameplay features.
Of course, it is not that bold and technical features affects gameplay and gameplay features have technical and so on, but you got the idea - keep the balance between gameplay and engine/ GUI/ data works.
Concerning upcoming technical week I have one BIG work to be started. Game should be able to keep world data in a client-server database. It doesn't mean, it should be on a external server, of course, but the game should work with it this way.
We need it for:
It means that main game may:
The most important part, main game doesn't care how database going to do it. Saves it to local drive, keeps in memory or uploads to fallenroguelike.com server.
For the game it would be 'a server'.
The development of game database can't be delayed for any longer.
Nearly all our upcoming gameplay features need it. It is as important as implementation of widgets.
We start discussing its architecture and prototyping. If you have any interesting suggestions, articles to read or very good with databases, you are welcome.
Any advise matters!
While gameplay weeks take 3 of 4 weeks in a month, technical week takes one. 3:1 is good ration for technical vs gameplay features.
Of course, it is not that bold and technical features affects gameplay and gameplay features have technical and so on, but you got the idea - keep the balance between gameplay and engine/ GUI/ data works.
Concerning upcoming technical week I have one BIG work to be started. Game should be able to keep world data in a client-server database. It doesn't mean, it should be on a external server, of course, but the game should work with it this way.
We need it for:
- game save / load.
- quests. Game can issue a quest, using world data.
- real server routines. It would be nice to allow other players' games to affect your gameplay.
It means that main game may:
- Upload its current state to the database.
- Load specified local level from it.
- Get any information game needs from it. (Do specified level has necromutans? Its seed? or specified workshop? etc)
The most important part, main game doesn't care how database going to do it. Saves it to local drive, keeps in memory or uploads to fallenroguelike.com server.
For the game it would be 'a server'.
The development of game database can't be delayed for any longer.
Nearly all our upcoming gameplay features need it. It is as important as implementation of widgets.
We start discussing its architecture and prototyping. If you have any interesting suggestions, articles to read or very good with databases, you are welcome.
Any advise matters!
Jul 4, 2015
Weekly report and build
Done list:
1. food gives bonus for eating it (needs balancing).
2. you can create fire using matches.
3. fire can be used for craft (One schematic!!! True achievement, lol.).
4. Item materials (stone, steel, flesh, paper etc)
5. minor fixes for savages.
6. config.cfg got more options. More to go.
7. campfire and pit actually prevents fire from spreading. Also minor fire fixes.
Current work:
Vadim is drawing super cool Casual clothing. There would be numerous variants of colours.
Jul 1, 2015
fire as a tool
Take your matches, pile dry wood or garbage and start a fire!
There a couple of balancing issues with fire. It too easy to make an arson instead of small fire and occasionally all town. Well, not all town, but burn down couple of houses is not a big issue.
Also, AI doesn't care about fire and luring enemies into fire works well. Except you don't get experience and their equipment burns.
I have two days to add schematics for fireplaces, like pit or campfire and add fire as crafting tool.
But I'll do my best to finish it today and take another story for tomorrow.
There are two more issues with crafting:
First, game doesn't show you as Player a report about crafting results. Was it successful or not, were is the result and so on. It needs disappearing pop-up message.
Second, crafting requires you to enter crafting menu, select a schematic, confirm it, select a tile. Doh!
Why so indie?
Crafting features on tile should be accessible via one click menu. For example: right click on empty tile and select "build" menu, or "fire/effects" menu and so on.
You should fight monsters, not interface!
Subscribe to:
Posts (Atom)