• 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.

Cruis.In

Members
  • Content count

    16
  • Joined

  • Last visited

Community Reputation

119 Neutral

About Cruis.In

  • Rank
    Member
  1. Hey everyone, the video demonstrates the use of some of the advanced defensive technology you will be able to out fit your ship with in the final game. https://www.youtube.com/watch?v=RWDBAdqP7Oo
  2. Hey everyone, I've posted two new video updates..   Combat: http://www.youtube.com/watch?v=y0pF4JsXgps&feature=youtu.be   Exploration: http://www.youtube.com/watch?v=ubbRDo28lJw&feature=youtu.be   Thanks!
  3. Hey guys, thanks for the support...   @Swift, appreciate it thank you :)   One thing about VoD is that even if it does fall a bit flat, I hope with the constructive feedback of the persons who have played it to fix and enhance it based on their suggestions.   It's one particular reason I hope to get a good set of active people in the alpha, before the game is finished. It will be much easier to develop it in these stages rather than after it is complete.   Thanks again   -Justin Project Creator Programmer
  4. its 2d view right so on the x-y you know where generally coordinates will be in that world. You can then specify specific dungeans etc to be specific places on the map regions, for your main dungeons, the one's you don't want to be randomly placed every time the game starts, which are central to story.   As for random, just use a function to randomize the x-y coords of placement. The numbers you specify can put things into very specific locations or boxes.   Like   place castle(  rand(10000, 12000, rand(1000,500) )   so the x and y placement is randomized. But you randomized it within a box, and you know where that box falls within the gameworld. You can widen your net or box of placement as you see fit. Create an array and loop through it for as many castles as you want.   I really am a simpleton, I am sure someone will come along with a nice algorithm you don't understand :)
  5. [quote] But does anybody know where I could learn to program games similar to Diablo? Or where i could start to learn such programming? Cause i cannot program 2D tiles, add sprites and make a character walk in a grid og 2D tiles etc I need to start from scratch. I know the basic C# programming, but not game programming.[/quote]   One important thing that helped me, an epiphany of sorts is that once you wrap your ahead around the concept that everything is abstract, then you can do anything.   I know it's over used but there really is no spoon.   There is no sword. There is no ship. There are no engines and there are no shields.   There are drawing graphics, variables, x, y coords, screen, input, output, checking for collisions and the consequences or results or action for the program to take in the event of a collision.   For example my ship has an "engine". It can be damaged, if it gets damaged, my ship cannot fly as fast. Remember there is no engine. Only a variable called engine. I could call the variable lightswitch if I wanted too and still have it affect how fast the ship flew.   your game is up and running, you are flying around your ship. An enemy comes and shoots a projectile, it hits your ship.   Abstract version: your game is running, a graphic in the shape of a space ship is being drawn around the screen based on the input from you, left right, up down. Another graphic comes along being draw, controlled by AI routines, and a projectile graphic suddenly is created at the enemy ship, it is drawn across the screen until its near you, in your game it 'explodes'. In abstract one graphic touched another graphic. You have a collision.   pseudo code   If projectile Image, collide with space ship image      stop drawing the projectile (delete the object, OOP)      draw explosion @ x,y coordinates of the collision      update the explosion, ( if its based on frames, a sprite)          if explosion complete (all the frames were drawn)          stop drawing the frames ( so you dont see a continuous explosion graphic)      endif        your_ship_engines = your_ship_engines - damage(damage from the projetile) end if   Now imagine how fast you can go if you speed is based on the variable 'your_ship_engines' the less value it has like say its 50/100 obviously you will fly slower. So your engines are damaged, and the effect of a damaged engine is 'simulated'   lets say speed = speed * your_ship_engines and let's say your ship engines starts with a value of 1.0 if speed was 100, you can go at full speed because the engines have not been 'damaged' no value has been subtracted from them.   but if you subtracted a value of 0.5 (the damage from the projectile) then the variable 'your_ship_engines' = 0.5   remember speed = speed * your_ship_engines (which is now 0.5) which means your speed is only half the speed you were capable of before.     I hope this doesn't get confusing, it's extremely layman terms, I am just trying to show you it's all what you know just with graphics. What happens on screen must be drawn, it must be updated, either based on input or something else. If you just want to make a 2d game I'd suggest using a system built for 2d games. Blitzmax or monkey, you don't need UNITY.   blitzmax is a BASIC programming language, but it's powerful and fast because it was written with C modules. It uses precompiled C modules. It can use OPENGL, directx, supports scripting, so your application can be cross platform from the beginning. Systems like these are designed to make your life making the game easier. For example for drawing that sprite you say you do not know how to draw? Command in blitzmax is drawImage(image, x,y,) . Where image is the image you are drawing, (pre-specified by you), x and y are the coordinates on screen. Because blitz renders 2d with hardware, its extremely fast, rotations are done real time etc, no need for frames etc. Blitzmax also has well developed 3d modules for it.   You can use any system which you feel is best and suits your need. Maybe Python with PYGAME. Haven't looked at python in a while so I don't know what other stuff is out there for it.   You could look at XNA , that seems pretty good and popular. I just stick with blitzmax because it is fast enough, powerful enough, cross platform, has dozens of thirdy party modules and libraries written for it and it's a BASIC language. My interest in other languages/systems is merely academical because I won't use them for much, but I still like to read/learn about them and try stuff with them.
  6. blitzmax is suitable
  7. if you just want to make 2d games, use something thats done a lot of work for you already.   blitzmax   you still have to learn to program, and it's in the basic language, can render your 2d with opengl (cross platform) or directX, so your programs work on mac/linux/windows.
  8. Thanks for all the help guys! Helped me wrap my head around it.   Haven't done this kind of math in like 20 years now. After many fullscaps later, I understand it a lot better!
  9. thanks for the reply,   ok im nearly there.....
  10. ok to normalize a vector   divide its x,y by its length   the vector in our example is -5,5 (vector towards target from player)   length = sqr( (-5 * 5) + (5 * 5))   length = sqr ( 25 + 25)   length = sqr (50)   length = 7.07   didn't you make a mistake in your magnitude calculation? since the brackets must be added before you find the square root?   normalized = -5/7.07 = -0.7 5/7.07 = 0.7         now that part I do not get. Could you word that better?
  11. disregard
  12. Paradigm: I understand somewhat that you have said, but not being much of a mathmetician I need it more layman.   How do I calculate the dot product of my normalised facing (which I believe is my ships angle) and how do I calculate the dot product of the vector to my target (which I believe is the angle of the target from me?)   Once done I am assuming from what you said, this gives the angle from the enemy vector to my facing vector. Once I have that angle, I can then allow "fire" once that angle falls within a certain value. And am I correct in saying that this would mean that once I am facing the enemy, the value of the angle between my facing direction and the target direction will be = to 0       Others no the cone isn't for range, it merely looks like a cone because of the lines etc.   the lines are just imaginary they do are drawn, it's just showing the vectors of the limits of your firing arc, merely to show the width of the arc I was seeking.   So basically its a front arc. If the target is in front of you, only then can you fire. Its top down 2d view. the 'camera' is focused on your ship which remains at the centre of the screen. You can fly about the game world, and rotate, similar to asteroids, but your ship remains drawn at the centre of your screen even tho u are moving, so unline asteroids in that aspect.   So imagine asteroids, imagine that you could only fire if the enemy was in front of you.   But I realise I think I have over complicated it and kind of fooled myself. Since it doesn't make sense to only be ABLE to fire if an enemy is in front of you. You should be able to fire all the time from the front guns on your ship.   What really complicated this is that at first I am using the mouse pointer as the aimer. So I can getting the angle of the mouse pointer relative to your ship, and offsetting it with your current direction of facing.  So if the mouse pointer falls within your frontal firing arc, you can fire in that direction, which is the front. So the front of the ship has a 60 degree arc. -30 to the left and 30 to the right. So the angle of the mouse cursor to my ship + the offset of my current ship angle was being calculated and held in a variable. I then stipulated that if that value is = within a certain range you can fire. These range is = to a small 60 degree arc.   So now I changed it to be independent of the mouse pointer, but instead to calculate where the enemy ship angle is relative to your ship, and if the enemy ship falls within those specified arcs to the front, then you can fire. Which really is a work around, because this means you cannot fire AT ALL unless an enemy ship is in front.   What I could do is allow you to fire all the time if the enemy is out of arc, but set the projectile to go straight ahead.   THen if the enemy is within the arc, the projectile is aimed at the vector of the enemy from your ship. So your allowed to fire all the time, whether a target is directly in front of you or not, just that the projectile will go straight. Now once an enemy peeps his little nose in front of your ship, the projectile will go for him.   Thank you guys all for your help, regardless of whether I rap my head around it I do understand more. Sorry to waste your times.
  13.   sure its blitzmax!     the problem is that although I know the angle of the target from my ship, that is just the angle of the target from my ENTIRE ship.  In this case, the firing arc is going to be a *frontal arc* so only if the player ship its target can it fire. Since the arc is a forward arc and its going to be narrow.   Since the ship can rotate on one spot while stationary, its possible for the angle of the target to be = to the firing arc, even though your ship isn't facing. Which would mean you could still fire.
  14. hey there thanks for the reply.   here is an actual view, forgive the placeholder art and debug stuff.   http://imageshack.us/photo/my-images/39/arcsss.png/   So the grey ship is mine. Always centered in the middle of the screen and it can move about the world. Rotate accel etc, but the camera is always fixed top down on it wherever it goes.   now if I fly around the green ship, I can get the angle of it from me using atan2.   But if I rotate that doesn't get taken into account by atan2. So the enemy ship could be at 60 degree value, and I could rotate my ship (let say I am now stationary) and my aft section will be facing the enemy, yet I would be able to fire, although the enemy isn't in my 'front arc'   So checking on the angle of the enemy from your ship using atan2 or anything else i've used and using the value returned it to see if it is inside your front firing arc isn't working out.   the firing arc is for my projectiles, not really related to collision