mousetail

Members
  • Content count

    112
  • Joined

  • Last visited

Community Reputation

2540 Excellent

About mousetail

  • Rank
    Crossbones+

Personal Information

  • Interests
    |programmer|

Recent Profile Visitors

11565 profile views
  1. WoA V - The Competition Thread

    Nearing the finish. Just a few more tweaks, and a few more crashes to fix.
  2. 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. https://neonlightgames.com/woa/Submissions#
  3. WoA V - The Competition Thread

    So Slicer just informed me I need to post direct links to this thread to count for participation points.
  4. 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.
  5. Day 4 - Movement

    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.
  6. Day 3 - Forts and stacks

    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.
  7. WoA V - The Competition Thread

    Day 2 is done! I have made about as much progress as should be for two hours, not days. That is what I deserve for trying out new techniques on a time limit.
  8. 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...
  9. Day 1 - I hate sockets

    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.
  10. Week of Awesome V - Administration Thread

    Woooo! Sign me up!
  11. Week Of Awesome IV - The Competition Thread

    My final version, in all likelihood, is here: [sharedmedia=core:attachments:32967] Have fun with it, and may the best win.
  12. Day 7 - Final

    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.
  13. Day 6 - Second beta

    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.
  14. 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) 5. Bugs 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)
  15. Day 4 - Updated menu

    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.