I have archers/ranged units. They cost money to build, and you get the exact same amount of money back by killing them then it cost to build it. This way, the total money in the game remains constant, but it may go from one player to the other. A good strategy is to try to get a large percentage of the money so the other player can not reinforce their lines. You can also see that units now form into a more natural formation instead of a straight column. The units tend to move back and forth a few times before finding a empty space though.
I have a better screen to make a connection, and show some game instructions at the same time. The game window is now re-sizeable, so you can get a better overview of the game field.
The game is pretty much done, as far as I am going to be able to come. There may be some minor tweaks, I really want to get some better way to deal with a broken connection instead of simply shutting down. Mistyping the ip right now freezes the program, which will crash after 10-15 seconds.
I have submitted a tentative version, though I'll probably fix some more stuff in the future.
I have a lot of screenshots today.
Here you can see my fancy new health bar on units. I kinda like the look of the text being slightly larger than the bar. I might use the same effect for the progress bar for training units.
The units can fight. They deal about 20 health every 0.5 second of standing still. That means a standing still unit can kill a unit moving past, while no damage is done in return. Also, a unit moving in will lose health first, and lose a 1 on 1 fight. This means you need a significant majority to be able to pull of a strong offense. I hope adding ranged units will make combat a bit more complicated, and introduce some interesting strategy on both sides.
It's possible to win, by destroying the opponents base. I even have a ugly technicolor screen to show you.
I seem to have introduced a bug where units can get stuck on the top right corner of buildings. There is a sub bug where this sometimes happens on only one computer. The bug must be somewhere near my new collision detection system. Hopefully I can fix that before the finish, since it's quite easy to make a unit invisible to the other team by moving it back and forth the corner a couple of times until it gets stuck on the other computer. Randomly moving it will eventually unstuck it again.
The next thing I have to implement is some kind of money, ranged units, and towers. If I have time it would be useful to have some kind of restriction on building stuff right in the middle of the enemies base. I don't really want a static line in the middle of the field, but instead I think you should be able to conquer more territory, like maybe you can build upto your own farthest unit or the enemies first building, whatever comes first.
I didn't have a lot of time today.
It is actually possible move your units now, and after some unexpected difficulties, it is impossible to move your opponents units. The target commands you can see in the terminal are of the form <unit id> <target X> <target Y> <elbow point time> <end point time>. This way, both players will see the units reach both the elbow point and the end point at the same time. In between start point and the elbow, there might be a slight difference since they start at a slightly different time. However, this distance is horizontal so it should be a lot less likely that something significant like combat happens in that time. If it does, the difference in time should be so minor a different outcome in combat is unlikely, and if it happens I will send a death event which will probably mean both combatants die. A noble sacrifice for the greatest virtue of all: to keep the games in sync.
The combat will work mostly the same for melee and ranged: When some kind of timer reaches 0, they will all look for enemies within range, and deal damage to random one. The range will be a lot higher for ranged then melee, and ranged range also get boosted when standing on towers. Both melee and ranged enemies will prefer to attack enemies of there own type, though I might skip that since I see no easy way to implement that. My framerate is already quite low, and the whole n^2 operation of computing the distances between all units will probably be quite significant. A framerate spike could potentially cause fast units to teleport through walls, and since the framerate might be quite different on both computers, that could cause the games to go out of sync. The whole double serverless simulation system is bound to cause a lot of unfixable bugs when the game rules get more complicated.
You can train soldiers now. Both teams have a fort now. Both teams can build barracks which can train troops. Right now, they light up in stacks, like this:
Soon, you will be able to actually tell the NPC's where to go. I have decided to forgo any pathfinding at all, and units will simply take a straight line path and simply stop and wait for further instructions when blocked by something, or attack it.
I tested the game on multiple computers today. Actually finding another computer with the correct operating system, number of bits proved to be a bit of a problem. Then I found a lot of my systems rely on synchronized system time, so the two computers spiraled out of sync even though the difference was only about 3/4th of a second. I might fix this, but since it can be easily manually fixed by turning on windows's automatic time synchronization, I don't think it's worth my time.
I think the game will be a little boring in a empty field right now as players will be mostly focused on defense. I might have some neutral towers and stuff in the middle so there is a rush in the beginning who can take control of those buildings, and encourage players to invest in offense right from the beginning, as well as some rocks to break the line of sight for ranged attackers. I will still see how far I come in implementing that.
I also think some kind of fog of war might also be fun. I just store the a y value something ahead of the farthest advance, and then have it very slowly retreat. This again motivates players to go into offense more often, instead of becoming a defensive arms race. I also won't have a way to repair damaged buildings, so players can make gradual progress breaking through the enemies defenses. They can buy new buildings of course, but I plan to make them so expensive that you have to save up quite long while you can invest a lot in offense in that time. Anyway, I should probably worry more about actually implementing stuff instead of inventing advanced features.
As you can see, now buildings built in one screen sync to the other. I have a system where it takes a few seconds to build something, and I send the completion time over TCP, then build another work in progress object on the other computer, set to complete at the exact same time. This way, even half a second lag will still not hurt the experience. (On the screenshot, you can see the raw data stream in the console.)
I also have a system where the players choose what sides they will play on. The basic system is that the first player to click wins. If both players click the same team at the same time, the both programs will generate a random number and the highest number wins. I haven't been able to test this system, and it will probably not actually work.
Aliens and Knights have different types of buildings. They will behave the exact same way as each other, but have different names and images. I am thinking I can get some humor from a rock wall being exactly as strong as a force field, or a laser gun doing equal damage as a bow and arrow. If I get as far as having flying enemies, the knights will have some kind of Davinci winged wooden contraption, with equal speed as the aliens flying saucer.
My next step is to give each team a fort. The game ends when the fort is destroyed. When I have a fort, I will not have anything to guard me from actually building the AI for the attackers. I don't think making complicated path finding will be worth my time. When encountering a obstacle, the NPCs will determine if going around left or right is the fastest. If neither is possible, it will go straight on ahead. (As all obstacles are breakable). Shouldn't be to much trouble...
Someone on my team had the genius idea of making our game multiplayer. I would hate that person if I wasn't on a one-man team.
The basic idea of my game is it's a 2 player tower defense style game, where both teams have to build troops and defenses, and the first to kill the others home base wins. One side will be the alien invasionists, the other side will have castles. The attackers will have some kind of path-finding system, like clash of clans.
It is my general strategy to get something playable on the first day, and work the rest of the week on polish. This time, sockets get in the way. Instead of the general client-server architecture, I need a symmetric system where both sides sent data to each other in the same way, and a third party can not join. At first, I tried using the python socketserver library. Both clients would start a server on startup, and prompt for a IP address. If you typed a address and pressed enter, the client would shut down the server and connect to the other server. The whole system was encapsulated and exposed only send, receive, and connect methods. The rest of the program did not care if it was client or server.
There was one problem, however: Socketserver could not keep open connections. I could send messages from the client to the server anytime, but I could only send a message back as a reply. This was of course, unusable as no message might be passed for a few seconds, so a signal could come way late.
I had found a answer earlier on stack overflow that used the sockets module directly as a server. At first, this seemed overly complicated, but having exhausted the earlier approach, and realized that using the same module for both client and server might save effort in the long run, I decided to go for that idea. I deleted all references to socketserver, and replaced them with copy-pasted code blocks from the answer, some of which I barely understood. The code I copied returned a new socket for every client. Since I need only one client, I decided to just delete the server and use this client object as soon as the connection was established.
I then spent some hours figuring out why messages where being passed from one direction but not from the other, untill I suddently found that my recv() call was inside a if (self.mode==CLIENT) block. So much wasted time.
Finally, I got both clients to sync state, as seen on the screenshot:
Hopefully, tomorrow I will actually get some game mechanics done. Hopefully my system will not break outside a local computer. Hopefully, I can fix those ghastly castle sprites.
Well, a friend my cousin nearly got addicted to my game, so I guess that is a good sign. It was a bit hard to get him away from the computer so I could load in the music. There are only a few minor changes, I made the spikes a bit less powerful, tweaked upgrade prices, added maximum levels to various buildings. Most of this stuff was only one line, and based on the excessive testing.
My final zip is only 8 MB, which means I don't need to worry about external hosting: I can just host it on Gamedev for now.
Now, I'll just have nightmares about the game crashing on the judges computers all night. Good dreams to you too.
Apparently, there where a few game-breaking crashes in the last demo. All of them where in code I changed, like, right before the build. I just hope I don't get those types of problems for my final submission. There where also some bugs, for example I refreshed the side bar before spawning the new citizen at the start of each day, leading to inaccurate population numbers in some situations. I also have a working music system, though I suggest you mute your speakers because the day track is a placeholder, generated by pressing audacity effect buttons blindfolded. The night track is still unfinished, RajaDavid is still working on it. I would really like if you could tell me about the spelling mistakes. There are bound to be millions, especially in the new help menu.
Good news! A new member is joining my team. RajaDavid will compose the theme music for the game. He is a skilled neoclassicist, and I feel that theme will work very well with the theme of our game.
To give him a feel for the game, I needed a demo copy. Since I have the build process in place now, I can easily share a build for you guys too. Initially, when thinking what to ask feedback about, I got a list of things spanning the distance between Cyprus and Japan. I have filtered out some of the most important stuff, I hope. Here are some questions to help, though you don't have to answer every question.
1. How easy was it to figure out the main mechanics? (Do you get the difference between healing capacity and healing power? Do you understand how houses work? Do you understand upgrade risk?)
2. Is the UI sufficiently initiative? It it easy enough to see how much money you have in different screens? Was is sufficiently easy to figure out how to navigate the screen? What about the menu? I tired to stick to conventions rather then explain everything, but the conventions are internally inconsistent also.
3. How was the game balance? Is any upgrade/building that is essentially useless? Did you find any game breaking strategy?
4. Was the game not complex enough? Too complex? Are there any ideas you can think of to make the game more complex without much effort? (eg. new type of building, new upgrade possibility)
Phew, the list did end up being very long. Your feedback is so important though, I get so blindsided by staring at my game for too many hours. I get versions mixed up, put off things for later only to forget them, tend towards strategies that lead to lots of bug spotting rather than victory, and generally misjudge what needs to be changed.
(edit: fixed bug in the last line I edited before uploading. I accidentally increased the lower bound of my random range faster than the upper bound, with all consequences involved)
The new main menu. There are fancy pictures next to the buttons. This was complicated because my menu system was based on putting items in 200 by 50 cells, to quickly redirect mouse input to the right widget, quickly calculate if attempting to scroll would have any effect, and allow widgets to automatically be placed in an empty cell independent of the size of other stuff. However, the images would be too big to fit into a 200 by 50 cell. I did want to keep the automatic placing, since I didn't want to calculate the exact positions of every widget whenever I add a new stat, but now the code for mouse events, drawing, and scrolling has become a lot more complicated.
Now, the citizen screen shows a image and a name! I hope that by giving citizens names and randomized colors, players will feel bad about letting one citizen die, even when he can immediately be replaced by another with full health. I also followed servants advice to make the eyes a little bit more blue, and lawnjelly's by making the eyes a little bit bigger and a little bit higher up. Either that helped, or I got so used to staring at them so many hours that I don't notice the creepiness anymore.
A blog post is not complete unless it contains a picture of zombies fighting innocent bystanders. I fixed some bugs where it was sometimes possible to do stuff during the night. Now, there can be absolutely no interaction until daybreak. Also, I chanced the obvious: I switch the grass texture out for a darker version at night.
I didn't have much time today, so I decided to gradually update the graphics rather than implement new features. Most of this stuff are simple blender models, with minimal effort. (Most of the work was getting them to fit into the frame). The new grass texture is actually a photo of grass, blurred, picked, and posterized into unrecognizability.
I still don't like the new citizen's eyes. I still fail to strike the balance between the eyes being invisible, and therefore creepy, or to big and bright, and therefore creepy. I think the citizens should be somewhat sympathetic, to motivate the player more, and increase the immersion. I guess I will just use my experience with making citizens creepy on the zombies.
In terms of programming, a fixed a bug where building could be built on top of each other, and also added a fix so you can't place citizens on top of building or each other. This is to prevent a strategy where you part all your citizens on top of each other on a spike pit, and do easy double damage, or even put multiple spike pits on top of each other.
I am really pretty happy with my progress today. I added different types of buildings:
House: Increases your citizen capacity. While you have less citizens than your capacity, new ones will spawn now and than.
Clinic: Heals a certain amount of citizens a little bit at the end of your turn. Prefers healing citizens with the lowest HP.
Spiked pit: does a little bit of damage to zombies that walk over.
Genome lab: Decreases the chance that your attempt at evolving a human turns it into a zombie. Expensive, every level makes it work slightly better. Limited uses per day
The upgade risk is the colored bar on the right. Black means the person dies; red, he turns into a zombie, blue, he gets a random buff; green, he gets the buff you want.
Zombie now spawn in increasing numbers as the game progresses. You get new money based on how many zombies you kill.
The art still looks horrible. It might improve. I might get used to it and forget.
There are also some ordering issues. Citizens tend to get stuck under buildings, where it is impossible to select them. There should be some kind of highlight showing what object is selected, and where it is going.
There is lost of stuff still to do, but I have seen published games on the internet worse than this. Not that any of those games are fun, but it's still an encouragement.
Everybody elses games are looking awesome to! Good luck.
If you remember me from last years, you know I had a relatively unambitious plat, and some hope of actually finishing. This year, not so much.
My game will be a TBS, involving ZOMBIES. You are in charge of a small settlement, and your job is to survive while zombie attack every night. Various buildings and upgrades can be purchased, and human upgrading will be known as evolution. Simple enough.
It seems like the gamedev image uploading system has gone a bit wacky, but here I try:
This is a picture of two zombies attacking two villagers. All art is temporary, hopefully it will look better soon.
Yea, it's still simple stuff. It will improve. Hopefully.