Bitcoin Forum

Hey ho, you guys might remember me as the guy who did Bitcoin Weekly, or maybe not.

In any case, I am developing the game called "The City" for bitcoin. It is going to be an epic simulation of a colony of humanity in a huge dyson sphere. Think Dwarf Fortress, except it's cyperpunk and technologically heavy. It's going to deviate in several ways: efficient chain management system and little micromanagement, variable production process, and knowledge is  actually a resource.

If you want to know further about the game: visit http://kibabase.com/projects/the-city

If you're interested in trying a demo despite the incompleteness and buggyness, you're welcome to try but it may break your computer. The link is on my project page which I mentioned last paragraph. Just don't expect fun yet.

Lately, productivity is very uneven. My motivation is not going to keep me going so I figured I need a crowd of people who watch the game development's progress and comment. That way, it'll keep me going even when I have low morale.

Lastly, this game is made possible through donation and is contingent on donation. I may ask for donation from time to time so that I am motivated to continue my work. My eventual goal is to be able to work on this game for a living.

If you have any questions, feedback, wishes, I welcome every comment.

Screenshots?

I am afraid I don't have any, though you can try the demo. It doesn't have much...yet.

Glad to see you're getting back into this project. I think the funding model is interesting so look forward to something playable!

Well... I don't get it at all.   ;D  But I think it's awesome you're developing a game for Bitcoin!

https://i.imgur.com/ceYFS.png

I never abandoned this project. I was only really quiet, but that mean nobody knows that I am actually working on something.

When you making circles, you're allocating stockpile points. Your units will then gather crystals, represented as deep blue.. I think the game suffered an inability to gather resource, so I am fixing it when I wake up.

kiba, you wanna write something for bitcoin media? either about your adventures with this game or about your thoughts on bitcoin gamedev in general? email me 'myusername'@riseup.net

That's a great idea for advertising my project. I'll think about it.

Interesting!

Posted a new log on the project page. The FPS of the game is dramatically boosted at the cost of extra complexity in drawing.

Been working all morning to fix issues related to FPS boosting breaking how objects are drawn. Camera and menu system are fixed. There are still more display issues to go but I am getting the hang of it.

Now, I will take a break and then work on something else before coming back to this project.

The only thing I see now is a black screen with 2 menu options, not much of a game :)

There is more than just two menu options, but it's still not much of a game.

Well I can't seem to get beyond new game and test arena...

Click on the game, anywhere. Press return/enter to select.

The redrawing bugs are almost gone. This give me a chance to focus on fixing all the bugs that are cropping up in the system.

Tomorrow, I'll fix some of the last remaining redrawing bug and getting the combat system finished for this development stage.

If you want to read up more on what I am doing, head to the game's project page where I post even more detailed development logs.

The combat system now have a proper dodging maneuver when opponents attempt to strike you. You can test them in the scenario "combat" in test arena. It's not completed though, because I need to add disabling effect to dodging when units' leg are injured.

Units are now color coded by gender to help better distinguish between units.

I am thinking of raising the price of development considerable or changing my business model to beat back the cost of maintaining my existence in the world. I paid 300 dollars a month to rent my own room from my parents. I also pay some money for cheap hotdogs and the occasional starbuck coffee, car maintenance, and so on. This mean I'll eventually lose all my saving in the process of creating this game and I will have to look for a real job again.

If I could get at least 300 dollars a month, that mean my burnrate will decrease to a level in which I will be slightly losing money. While it won't make me profitable, it will at the very least increase the longevity of my ability to work on this project. If I found a way to make myself slightly profitable, this will let me maintain my project indefinitely. It won't do much to increase my ability to survive emergencies, but it will help maintain my current lifestyle atm. It meant that I can dedicate my time toward this project and build my magnum opus, the video game that will encompass my life's work. It is my dream to be able to do this, but if I need to put food on the table, I will have to set aside this project of mine or work dramatically less each day on this project.

So how do I reach this 300 dollars worth of bitcoin goal?

We could continue the previous model of spec driven development. Each development stage, I promise to achieve a certain set goal and once funding is done. However, if I added a lot of things for this stage, I basically overwork myself. This is the currently the case. I have not gotten any new funding since more than one month ago because there was so many features that I need to achieve before asking for more funding.

I could go toward another direction. Instead of completing milestones before asking for more funding, I ijust aim for weekly goals. If I achieve my goal for that particular week, I would simply add more stuff to work on. Otherwise, I need to scale back. Users can see the progress I am making on a day to day basis, assuming I didn't forget to deploy. Users are free to donate as many bitcoin as they like. Perhaps users can get little extra something if they donate enough bitcoin, perhaps a drawing or a short story. This could be a way to improve my writing or artistic skills! I am basically imitating the Dwarf Fortress business model, except that I have a much tighter feedback process. Donation usually peak when a new version of dwarffortress is released, which can be very occasional. I, on the other hand, pretty much release new versions to the public frequently. I think this business model suit me a lot better than the business model I am on now.

I am leaning toward the second business model. It's more suited to my style of development. What do you guys think? Do you think I could feasibly achieve my goal or do I have to get a real job developing website for clients?  I think the biggest question is how many people are willing to support my effort. I don't have any loyal fans yet because my game doesn't have much for people to have fun with. It may be a long time before I can achieve even a minimum of 300 dollars a month in bitcoin.

Maybe if you provide some idea of what it will look like in the end. So far I have just been confused. My H ran into a blue square and then made a circle then I couldn't do anything.

Does it keep going to the blue square and going back to the circle and making triangles? If so, we can conclude it is gathering crystal stockpiles.

My game is harder to understand because both I didn't work very much on making it understandable and because it's a game where you don't directly manage units. It will take time for me to figure out how to help players understand what's going on.

Anyway, thanks for the suggestion. I will write a post on the overall version of the game. Maybe this will help get funders on board.

Also, I forgot to mention that I applied for a researcher position for a charity. I doubt I'll get the job, and I estimate a 90% likelihood of failure to get the job. We will know in an estimated 1-3 weeks, because I have to complete an unpaid test research project. If I manage to somehow snag the job, I can still continue to work on this game even if it is in reduced capacity and my situation will be far less fragile. It's better to having written the game, rather than not at all.

It seemed like it locked up. I couldn't move around (I figured out using a,s,d,f earlier) or anything. You should also place the instructions in a clearly marked location, I just figured it out by pressing buttons.

This could be a bug, but I need steps to replicate this bug or ortherwise I can't fix it.

You need to post up an explanation of what everything is/does.  I have no idea what I am looking at when I load up the game or start clicking things.

Correct me where I am wrong:
H = the unit you are controlling
Black = ??
Circle = some sort of safe zone
Blue square = crystal mine
Triangles = crystal stockpile

So right now, is the whole point just to gather crystals?  What will future goals of the game be?  How will you win/lose?

I wrote some initial non-comprehensive draft about the game and what you're seeing. There will be more information as I update it.

http://kibabase.com/articles/the-city-game-design

http://kibabase.com/articles/gameplay-description-of-the-city

Cool, thanks!

Primary work is on the combat system today. I should be finishing it anytime now. Once that is done, I will put in the final piece for this particular milestone.

I finish all the milestone goals for "Stage 2" of development. What a journey! I am letting the weekend ferment the game into a polished and unbuggy but unfinished game while also giving me time to write a report.

Phew! I am glad that I have the grit to continue for more than 2 month in development. Time will tell if I will spend decades developing this game.

A report on the game: http://kibabase.com/articles/the-city-stage-2-development-report

watching

I did a pure bugfix coding session. I discovered a lot of drawing bugs that are now fixed. I still have a couple more to go.

Thanks to whoever donate 5 BTC!

I lost a day in development, because I was busy revising an article, submitting it to Hacker News, and watching traffic spike. Then, my internet connection went down. So I didn't have a chance to work on the game that night.

The game seems to freeze whenever I place a crystal stockpile on the edge. Do you have a place to report bugs?

Bug is known. I have a github page for this: https://github.com/kiba/The-City/issues?sort=created&direction=desc&state=open

First day development resume. I spent all my time fixing annoying pixel imperfection because drawing efficiently is a complex affair. Otherwise, the game now autofocus so that you no longer have to click on the game to start playing with it.

Now it's closed.

I realized that I didn't deploy yesterday. I'll have to change my policy again so that it won't happen again. Also, I will be working on code that massively disrupt the game's codebase, so don't expect new deployment as often.

For today, I added more information in game on how to use it and prepare for work on pathfinding, which consists of adding walls to the game and building a scenario for it.

I also wrote more on the overall development arc, including what's to be expected in the next few weeks as far as development goes.

http://kibabase.com/articles/the-city-development-arc-the-conveyor-belt

I did another coding session before the day is out. This time, you won't see much of anything change, because I am merely changing the underlying data structure. I also started work on pathfinding. Tomorrow should be the day when I focus exclusively on pathfinding. With any luck, we may be able to accomplish the weekly goal list before it's supposed to get started.

No deployment yet. Various bugs and kinks are worked out after the pathfinding system break up everything. I think there's more to fix before I do a deployment. There's also the issue of the algorithm for pathfinding may not be implemented properly. It's my first time with a pathfinding algorithm though.

Tomorrow is video devlog day, in which I will record a youtube video to show off what I been working this week.

Yesterday, I was too tired to do some work and spent most of my time sleeping.

Note to self: no more sugary drinks

After several days of codewacking with the pathfinding, I finally hammered it back into a usable shape. The game now have true pathfinding, HURRAH!

Also, I got started on procedural generation. First, I got rid of the white floors, and stop generating them completely random. Instead, I path to each blue squares with gray floors. It's not completed, and I am not sure that's how I want the streets to be like that anyway.

I should be generating buildings at some point later this week.

Ok, I'm starting to see some logical action of Hs going from dark blue to the light blue squares I put down. I was hoping the Hs would choose closer crystal piles when I set them down but what fun would that be? Glad to see it moving from totally conceptual to slightly functional. Is there a way to see any stats on this crystal gathering process?

Finally. Some feedback!

Status is mainly in the form of crystal piles going from black to blue. The changes is very subtle, so it only let you gauge somewhat vaguely.

I just finished developing the tooltip system today. It let you see figure out what object is on the map, although it doesn't see any description of units. In any case, the tooltip will be an ideal place to learn about how much crystals are in a single pile.

In other news, I did some work on thickening the paths between crystal trees and getting it looks right. That doesn't seem much, but behind the scene, I am really building the proper toolkit that allows me to generate buildings.

What I been doing for the last few days is just working on the terrain system. It's a hell lot more work than I thought.

I also built a primitive help page. It's not much but it's better than nothing. In addition, I worked on scenario reloading to help me test better. The game is now 3.5 Kloc!

It may seems that I been dead for a whole week or something, but I am continuing my mission!

Right now, I am developing tree cutting and mechanism to support tree cutting. I plan to complete the feature with "TIMBER!" everytime the logger cut down a tree. It will also have "accident" mechanism in which an unlucky creature stuck at the wrong location and the wrong time will die in a tree felling accident.

Anyway, I scaled back development way back since people are not donating any BTC to justify my desire for full time development.

Can you give us something to do while the H's are doing their crystal/wood collecting thing? Like maybe you can hide some items in the darkness or have us so some simple math or something? I think to have much more support, you need to give your users some satisfaction of having completed something.

I'll have to divert my development effort to add a small worthless placeholder feature in the game that takes an hour to implement. This meant, the tree chopping with satisifying "TIMBER" notice will arrive slower, along with other gameplay feature that are in the pipeline. Keep in mind that my time spent on this project is by necessarily limited due to low donation. It's a real opportunity cost.

Important gameplay features come first. Next is the tutorial and system that allow players to discover and learn how to play this game. The rest of everything is on the backburner.

Few donate because nobody found the game interesting yet. Some people even thought that this game will never be fun! So my priority number one is to build the big system needed to have fun. Resource gathering, production, military organization, combat simulation, social system, etc.

I noticed a file about the base unit system is 145 LOC long. That trigger a MANDATORY rewrite. The remedy was code reorganization. The combat mechanic got a whole file dedicated to itself.  This took a significant chunk of my time out of what I am supposed to work on. The upside is that we get cleaner code which will save me time in the future.

Next, I continue work on the meta system for jobs so that stockpiles can assign several different type of jobs at the same time.

Is 145 LOC too long for a base unit system? Considering this is JS, that seems awfully short.

Who would think 145 LOC is awfully short?  :o Now, it's written in coffeescript and I only care about coffeescript. The output might be bizarrely complex for all I care.  ;D
It is per my hacking policy that I slim down any file longer 100 LOC to take care of technical debt that accumulates. You don't want to spend all your time writing them up and making it clean only to mess them up with extreme code addition but you don't want to wait too long to the point that it slow down your coding to a screeching halt either.

Anyway, my output is too irregular lately, thought it's a normal considering that I have my up and downs in motivation.

Lately, the code been giving me hell as I come to grip with old code and try to understand it. I reorganized the map file once again(it exceeds 100 LOC regularly), consolidating collision check functions into the Collision class. That gave me a lot of errors in my code in which I have to jump around to find. Very frustrating since the environment don't produce useful stack trace to use.

I finally got the gatherer unit to look for timber, not trees. However, there's a bug in which it will pick up a timber at the stockpile location and drop it at the same location again and again, which took me a while to figure out.

I tried to use an untested collision function that unsurprisingly doesn't work. I'll have to figure out how to make it work.

It turned out that my collision function was already tested and useful! I also figured out how to use the "debugger" statement, which will allow me to figure out all kind of stuff faster.

Anyway, I solved the bug behind gathering timber. Now timber actually disappear and picked up and dropped, etc... We now move on to add addictive cutting, which mean that if you want to chop down a tree, you have to do it several time! For tree, it takes 10 times. Cutting down logs will always take one time. I did some preparatory work on floating texts so that we can have "TIMBER" and chopping texts for cutting. (In the future, we might have audio sounds for those kind of things)

Also, a lot of thing are broken, so once the logging feature is completed, I will begin to fix all those regressions that are around before we can do a deploy.