• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

2525 Excellent

About mousetail

  • Rank

Personal Information

  • Location
    Delhi, India
  • Interests
  1. My final version, in all likelihood, is here: [sharedmedia=core:attachments:32967] Have fun with it, and may the best win.
  2. 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.
  3. 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.
  4. 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)
  5. 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.
  6. Your graphics look amazing. Good job.
  7. 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.
  8. 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.
  9. My blog is here: http://www.gamedev.net/blog/2216-mousetails-woa-4-journal/ there seems to be some problem with the images in the blogs, I hope it's just my browser.
  10. 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. The plan 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. The progress 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.
  11. So, the last week I have been making a quick and simple casual game about drawing circles around dots. It looks like this: [attachment=32561:011.png] The tabs on the right indicate how many dots should be on the circle. Depending on the color of the dots inside of the red line, you get a certain amount of score. The game is intended for touch screen eventually, but it plays fine on mouse as well. I kind of want to have a name before I enter the polish stage, but I don't really have many ideas that I think would work. Luckily, I have you all to help me! See it as a game, try to post as many possible names as possible, the more crazy the better!   The rules are: 1. Post as many names as you can think of 2. Try to have the names be at least two words or at least long words 3. There are no rules, disregard anyone who claims otherwise
  12. Thanks, that works. Look at those beautiful rectangles. [attachment=32460:008.png]
  13. Good catch, however, rendering two triangles now means it took the first 2 verticies from the polygon instead of only the first, and it looksallmost the same considering how close the vertices of the polygon are together.   At startup, the verticies of the rectangles are defined as: VertexPositionColor[] rectanglePositions = { new VertexPositionColor(new Vector3(0 ,0,0), lineColor), new VertexPositionColor(new Vector3(1000,0,0), lineColor), new VertexPositionColor(new Vector3(0 ,200,0), lineColor), new VertexPositionColor(new Vector3(1000,200,0), lineColor), new VertexPositionColor(new Vector3(0 ,900,0), lineColor), new VertexPositionColor(new Vector3(1000,900,0), lineColor) }; static int[] topRectangle = { 0, 1, 2, 3 }; static int[] bottomRectangle = {2, 3, 4, 5 }; They seem pretty straightforward...
  14. So, I needed to draw two filled rectangles and a polygon in Monogame. Now, based on my research, the normal way seemed to be making an orthographic camera that mapped 3d coordinates exactly to screen coordinates, then using drawUserIndexedPrimitives to draw arbitrary rectangles to the screen space. The code for the projection is: effect = new BasicEffect(graphics.GraphicsDevice); effect.World = Matrix.CreateOrthographicOffCenter(0, GraphicsDevice.Viewport.Width, GraphicsDevice.Viewport.Height, 0, -1, 1); effect.DiffuseColor = Color.Red.ToVector3(); I use the same effect for all 3 shapes. (Should I?) Next, my drawing code: foreach (EffectPass pass in effect.Techniques[0].Passes) { pass.Apply(); GraphicsDevice.DrawUserIndexedPrimitives(PrimitiveType.TriangleStrip, rectanglePositions, 0, 4, topRectangle, 0, 2); } effect.DiffuseColor = backgroundColors[colorIndex+1].ToVector3(); foreach (EffectPass pass in effect.Techniques[0].Passes) { pass.Apply(); GraphicsDevice.DrawUserIndexedPrimitives(PrimitiveType.TriangleStrip, rectanglePositions, 0, 4, bottomRectangle, 0, 1); } spriteBatch.Begin(); ... effect.DiffuseColor = Color.Red.ToVector3();             if (polygon.Count > 4) { foreach (EffectPass pass in effect.Techniques[0].Passes) { pass.Apply(); GraphicsDevice.DrawUserIndexedPrimitives(PrimitiveType.LineStrip, polygon.ToArray(), 0, polygon.Count, indexData, 0, polygon.Count); } } The vertexes for the two rectangles are stored in the same array, since they share two vertices, which need to be updated every frame. [attachment=32444:006.png] However, before the polygon exists (When polygon.Count <= 3), only the top rectangle is drawn. Afterwards, the bottom rectangle seems to make a wierd triangle from the right first two vertices, but ending at the first vertices of the polygon. The triangle also flickers to other verticies occasionally. Am I misunderstanding how drawUserIndexedPrimitives works, do I need to call some reset function in between draws, or what am I doring wrong?
  15. Yes, I'll actually have a free week that time! Count me in, as a one-man team (I'll make a blog here on gamedev closer to the start date)