Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by Daaark

  1. The crappy embedded chips we have now are complete shit compared to what we had in the 90s. They pick up interference from everything else in your rig, and they often chug on simple tasks. A significant cause of android's keyboard lag is the crappy chip trying to replay the typing sound over and over. Lots of lag with embedded chips comes from waiting for sound data to be moved around and play. When the chips can't keep up you get stuttering, popping, or dropped frames. My almost 30 old SoundBlaster 16 is laughing at this. I wouldn't blame MS for this. Eventually it just got cheaper for OEMs to use cheap embedded parts at low or no cost than to include more expexpensive parts from other vednors. It also lets them keep the power requirements lower. The same thing happens in the GPU space. We get embedded chips and 200W PSUs.
  2. I work at 1 unit = 1 meter. But this doesn't matter. Whatever works for you. A lot of tools standardize on 1u = 1m though. A skeleton joint for the most part just rotates. When you attach a finger mesh to a finger join, and then move that joint 90 degrees, it just means all the vertices attached to it move 90 degrees too. It doesn't matter how big the skeletons or characters are. Every vertex just takes on the rotation from the bone(s) it references.
  3. No, Zen 5 is a simple 2D top down game. I play(ed) it until the micro-transations got ridiculous. It's a tile map and sprites. But that's beyodn the point, because he was talking about the look and style, not the code-base, which I know is something this community has a very hard time grasping. I had no problem making a 2D top down RPG 6 months into my programming career, because I was focused on getting stuff done, instead of coding just to code, like a vast majority of people who hang around places like this do. Like that nice article that was posted today of someone who screwed around for 9 years and made no progress, making the same mistakes most people who posts in communities like these make. Everything in Zen 5 and similar titles (they are flooding the mobile market) is standard stuff that have tutorials adnauseam (I didn't have access to those when I started). There is a billion and one tile map and sprites tutorials on the internet, and if the Op spends a month or to learning Java, he can have a sprite walking around a tile map in a day or so. Then he has plenty of time to implement a Zen 5 style game. But with an attitude with yours, I'm sure it's more than impossible in ten years. It happens in every creative community. Those who want to create, create, and those who can't just hang around those that can and talk about it every day for years, producing nothing. But it's fun to throw those buzz words around!
  4. This is the epitome of why this forum blows. If you're not going to leave a thread better off than how you found it, why bother posting? Zenonia 5 is an simple android top down action RPG. It's 90% design and 10% programming. It's not some big, insurmountable goal. For android you'll want Java (read a book and learn it all first, if you jump ahead, you'll spend your entire year stuck on trivial things) + libGDX (don't touch until you complete a java book) will cover your programming needs. RPG Maker (now available on steam) is a much better choice, but they don't seem to have android support. The developer says they have been working on Android support, but that doesn't mean it's coming any time soon, or that it will even work well. Character design is not a technical thing. Get a pencil and a notepad and start creating. Figure out what your game is going to be about first, and then design characters that will take on the roles needed. When your design is finished, you'll know exactly what you need and an start working on them in a paint program. Keep your game small, simple, and focused. If you want to finish it in a year and a half starting from scratch you'll have to dial it back to something small, like 1 town and one randomly generated dungeon. If you can finish that, you can use it as a nice base to keep working on another game after that.
  5. Daaark

    My new game - Worthy or does it suck?, sell or rot

    Both the web page and the game are a complete eyesore of bad clip-art and clashing colors. You can't mix photographic and non photographic texturing, it just looks like a a mess. You have no set style in game. It just a bunch of random art styles mixed together. You can't have shaded stuff and non shaded stuff in the same scene. For instance your fully shaded pig on top of a full bright raft. The color of that raft cannot possibly exist in that scene, unless it happens to be emitting light. The title of the game, flashing inside the skybox is probably the poorest choice graphically. It should be on a screen aligned quad. The colors in the title clash heavily with everything else in the scene. Also, the skybox being so close is also a poor choice. It's being used in the absence of a fully finished 3D scene. You can't just have 10 feet of water and then a flat wall with completely out of scale (and non matching) trees. The main menu and the game HUD bleed into each other. The game doesn't even work. When I try to walk, I just roll around in the terrain. Arrow keys to move also scrolls the actual web page. The camera is crazy and goes all over the place. Don't be discouraged though. Keep refining it until you have something nice.
  6. That attitude in general won't get you very far. There is always a new language, skill, or technique to learn when developing something!
  7.   You know, I never even thought of doing that, despite having done something similar with satellite images back in architecture school (obligatory "don't go to architecture school" warning). Guess I learned something new. Always work from reference. Some people use images in the orhto views, and some people throw up textured planes into the 3D views. Here are some popular figure references: There are also topology guides you can follow so you have a good idea of how your edge flow should be set up for good deformation.
  8. Most models, especially characters are modeled on top of reference pictures that are dragged into the 2D viewport. It doesn't matter what size they are, because the proportions will never change. Just drag them in, and line them up so that the front and side views match up. Don't worry about the scale until you are done. When you are happy with the model, remove the reference images and scale your model to whatever height you want. If you're using 1 unit to a meter, then your model will end up 1.8 units tall. You can use the same skeleton for all your characters with some exceptions. You can re-target, or even copy and paste the skeleton from one model to another. As long as the characters have the same number of joints.
  9. BlenderCookie, Youtube, and Vimeo. The official Blender books are expensive, and the software changes very quickly. Blender typically does a big new release every 2 months, so those books are out of date almost as they come out. Any cheap books you might find will usually deal with it before the big 2.5 redesign and will be almost completely useless. I think video is much better for something like Blender. It's not enough just to know what does what. It really helps to see the workflow and how people actually use it. You learn a lot more by watching someone model stuff then just reading what each button does.
  10. It's native windows + D3D? Look for a function called SetCursor(false) and change it. Or WhateverD3DDeviceIsCalled->ShowCursor(false);
  11. I googled it, and it looks like someone's example framework. Most likely, the author just told the program not to show the cursor. Do a search in the source code for the word cursor, and look for the line where they set the cursor visibility to be false. In XNA GS the line would contain IsMouseVisible = false. Comment it out, or change it to = true;
  12. Get a good book that assumes you know nothing about programming, and follow along with all the C# programming exercises. Then learn how Unity3D works, and you can import models and script their behavior. 3D modeling only seems hard until you understand how it works. After that, it's purely about creativity, and how much time you want to put into it.
  13. Learn C#, grab Unity3D, and then follow along their 3D platformer demo project at : You will also need to learn how to create content. I suggest grabbing Blender and learning how to model, animate, and export to unity using the videos at
  14. Daaark


    Put your showcase work on your website. Use DeviantArt for everything else.
  15. I don't care for the Unreal Engine as I don't like the way it handles things back when i used to use it. So I can't answer your question. C++ programs take time to compile. I can see them letting you compile game behavior into a C++ dll, and maybe recompiling and swapping that out. It will not be instantaneous, and not something you'd use on per frame basis. (For reasons listed in other posts, I wouldn't want to write If 500 people post looking for a gameplay programmer, you will 500 different answers from them. Programming requirements are often specific to each individual project. C++ is not a requirement to get a job. It's a common requirement to get a job at certain companies making games, however. This is a different issue than choosing a game engine based on C++ or scripting language use. That's why I gave you 2 answers to 2 questions. If you want to make a game in your own time, make a game. -Most people making software use C#, Java, or domain specific languages (html5, perl, ruby, adobe flash, fortran, cobol). Software development is a large industry, and C++ is not king everywhere. -Gaming is moving to mobile platforms, where objective C, Java, and scripted engines are king right now. All the games on XBLIG are in C#. C++ can be used on Android, but it's a pain in the ass and you have to jump through hoops. It's highly discouraged by the Android team, and is more for portability reasons than for speed. -Self employed people can make software using whatever they like. You can use any combination of programmer and scripting languages. Lots of popular shareware software that used to turn up on the CD racks at retail stores was written in Visual Basic. -The language that any software is written in is not an important. It's a meaningless implementation detail. It has no effect on the usability or productivity of your software. It's all about personality, presentation, and quality of the content presented. If the software is meant to do a specific job, then it's about how well it does that job, and how well the interface eases the process.
  16. Yeah, that inventory stuff is all simple programming. It is just a list. Complex ideas do not mean complex programming. Everything you mentioned is just a few lines of code attached to different events that reference that list. The code will more or less look the same in any language. Scripting languages aren't dumbed down. They often aren't 'scripting' languages at all. They are full on languages that can do anything, and as I said in my post above, they are only called scripting languages in the context that they are being hosted in another program. They exist because they have different goals than C++. They let you model problems at their face value and ignore machine specific technical details that have nothing to do with the problem you are solving. C++'s purpose is to be a portable language that targets system level programming. It's good at moving memory around and doing complex calculations really quickly. Other than ASM, it's the best too for that job. It can leave a lot to be desired in other areas though. Other languages are better suited to different tasks, and to express different ideas. C++ is all about machine level details, but when the problems you are dealing with have nothing to do with those details, C++ can actually become a hindrance. Sometimes you just want to process text and numbers at face value (instead of as char arrays, and numbers as objects with bit limits and sign issues). Sometimes you want 8 to just be 8, and not a representation of a 32-bit unsigned integer. Sometimes you want to deal with words and phrases, and not character arrays or strings. There are languages that can hand C++ it's own ass in these areas. That doesn't mean C++ is bad. It's just not what C++ was designed for out of the box, and it can't express those ideas as neatly and elegantly. So it turns out that the best tool for the job is to use a C++ to solve the system level problems, and host a virtual machine to handle the actual game. The engine can then be small and fast and focus 100% on it's area of responsibility. The scripts can be executed quickly, changed on the fly, without recompiling anything, and won't introduce bugs into the executable. The scripts also add almost infinite possibilities to what an engine can do. It's a win/win situation. An engine will take 10,000 objects in a scene and do a quick collision detection pass on them. It will then generate a list of collision events, and hand them off to -> The scripting engine, which will handle collision response. A script will fire and it will know which object it collided with, and have a data structure passed along with all the other relevant information. You object can now bounce, disappear, turn green, blow up, play a sound, trigger another event, generate code on the fly, or whatever else you come up with. The engine does the detection because it's faster, it's technical, and it's standard behavior, not needing flexibility. The script handles the response because it needs to be flexible and open ended. Most scripts will be dealing with event reactions, which are rules, and not technical details. These are not 'c++ / system level' problems. It's an industry buzzword, and a C++ programmer can easily learn any other language. A C++ programmer will have experience dealing with systems on the low level, and can be switched around to different tasks with different amounts of required technical expertise. There are many different tasks in programming a game. You may join as a scripter and only ever write lua/C#/java/python/etc scripts. However, when that task is complete, it's nice to be able to do other things, or you will become redundant when they don't need anymore of those scripts written. C++ deals with the machine at a very low level. It's easy for a C++ programmer to jump into any higher level language and be somewhat productive immediately. Because it's all the same concepts, but you don't have to be as specific, and don't have to manage memory. It's harder for a someone without C++ knowledge to jump into C++ because you suddenly have to know how to think in terms of memory management and being specific. I never said not to learn C++. I said it's not required to make a good, fast, game, and certainly not desirable to find a C++ only engine. You can use an engine and create tons of successful games without ever needing to write a single line of C++.
  17. This sentence doesn't make very much sense. There is no distinction between programming and scripting that needs to be made. Scripting is only used as a context to describe the programming where you tell an existing program what to do, instead of the programming that is done to make the actual program in the first place. This allows a program to be small and fast, and just describe some basic object models. After that, it's handed off to the user to create scripting data to tell it how to behave. Gameplay interactions have no business being in the engine code in the first place. The engine has it's own single area of responsibility. It manages memory, takes input, checks for collisions, draws the screen from a list of visible objects, etc. It doesn't need to know or care about your inventory system, or what a quest is, because they have nothing to do with it's job. For instance, the engine has defined generic game objects, and triggers. It has events for when an object enters and exits a trigger. The user of the engine can hook into these events with a script. The user can now write a script to define what happens when an object enters or exits a trigger area. The possibilities are almost endless, and any type of action can now occur without having to change the actual engine program. The script becomes content, and can be loaded, swapped for new ones, and possibly modified on the fly. They will get trashed like any other data when they are not needed anymore. Scripts are mostly safe, and usually will just be halted with an error message instead of crashing the whole program. Usually you just get bad behavior that you can isolate and fix quickly, and then you don't have to recompile your whole program. The script is just a file in a folder. No different than altering a texture or a sound. If your inventory and quest systems are big and complicated, then you doing them wrong. An inventory is a just a list of some custom data structure with a few functions to manage that list. When it comes time to draw the inventory, you just tell the GUI skin you customized what items to draw in what slots, and the engine takes care of adding it's standardized GUI with the correct image references to the render queue. What if you don't want that? Tell the engine to draw your inventory items dangling from your belt by making one call to add the model to the scene graph. What if you don't want that either? Tell the engine to draw a floating model of your inventory object on the top corner of the screen. etc...etc...
  18. Why make poor decisions because of stupid, self imposed rules? C++ is used for the system level code, and scripting engines and VMs are used for the actual game logic. This isn't slow. This has been done going all the way back to the 80s. Game logic is just content. That's why engines like Unity3D and Unreal don't give C++ access. Because that part of the job is already done. The things that you would have written in c++ instead of the scripting language are already written and working.
  19. Yep, just a bunch of spoiled kids crashing the ballot. We also have companies do any combination of hiring young workers, paying below living wage, and building camps for their employees to live in. Why pay an employee at least a living wage, when you can build him a 10$ hut and put a cot in there for him to sleep on? He doesn't need living wage then, he's basically a prisoner doing labor so you can get your product a few dollars cheaper. Employees committing suicide? No problem, install a 5$ net, so you can catch them when they jump, and send them back to work instead of treating them better.
  20. If you rank the top 500 things in order of severity, that would be the one of the lowest things. They pretty much own the water supply in one South American country. You can't collect rain water off your own roof and drink it. It belongs to Coke. They are accused of telling people to quit their unions or be killed, and then further accused of actually following through with it. ther e is more than one case of this, in several south american countries. They are accused of using highly polluted waste water (to cut costs) in some of their over seas bottling plants. They had Nazi ties. I could go on listing stuff all day, and of all the stuff I am aware of, it seems to not even scratch the surface. Using polluted water, killing people, making coke cheaper than water in some countries, lawfully owning every drop of water, etc, etc, is qualified as poor interaction with customers.
  21. open blender, scale in object mode. Hit Ctrl-A to apply the scale to the identity matrix, export back out.
  22. Those are a bit of a stretch. Those guys aren't evil, they are just delivering poor service. They should look towards companies committing actual acts of evil, like Coca-Cola in some third world countries. I think the documentary (The Coca Cola Case) on that is still free to view online somewhere.
  23. Make sprite sheet with whatever characters you want. Problem solved.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!