Show Posts
|
|
Pages: 1 2 3 [4] 5 6 ... 10
|
|
61
|
Community / DevLogs / Re: Nono's Adventures in Amazonia (Point and Click Adventure for Tablets and Phones)
|
on: February 07, 2014, 07:51:01 AM
|
Whoa! Now there is the MAP EDITOR! Lots of things cannot be edited art, and as you can see my programmer art in the map editor menu is totally awesome...  What I am doing on that screenshot is edit the click area, the white rectangle around the monkey is its actual sprite size, it is too big to be left click-able (and might introduce issues, like overlapping other things and making them impossible to interact with), the blue shape around it is the click-able area. The circles are the handles to edit that area. Red on scene are items (the ones that go in the inventory), green is stuff that change level, none is available on that scene because I did not played enough to unlock the exit... Yes, I can play and edit at the same time (or... sorta same time, I can alternate between play mode and edit mode). This make editing the map much easier in my opinion. (unless you are clueless and don't know how to solve your own map). Custom engine for the win =D Also some people might be wondering: Why the hell make a full blown engine? It is because this will be a series with many games (the first is nono in amazonia, but there will be also nono in savannah, sahara, city, whatever other idea we have...), eventually the engine will be good enough so artists and level designers can make the whole game without help of any coder (and at that point me and the coding team will be doing some other game engine for another series, probably a platformer or something like that).
|
|
|
|
|
62
|
Developer / Design / Re: player attributes, too less?
|
on: February 05, 2014, 06:35:25 AM
|
|
If that is the case you should use 3 attributes, and use a rock/paper/scissors relationship between them.
A theoretical example that probably would not work... but...
Defense trumps Attack Attack trumps Speed Speed trumps Defense
Defense wins against attack, because a character even with high attack still do damage too slow to defense character, and thus the defense character can counter-attack damage attack character faster. Attack wins against speed character, because speed character has shitty defense and will take a beating. Speed character wins against defense character, because it can avoid defense character counter-attacks, and his high attack speed can do some good damage to it.
That was only an example, but using rock-paper-scissors is a good starting point for any game balancing.
An RTS example:
Cavalry Beats Archers, that Beats Infantary, that Beats Cavalry.
The reason being that Archers are defenseless, and attack too slow to kill approaching Cavalry (that quickly kill them all when they close). Infantary instead is too slow to outrun archers or approach them, and just get shot to death by the Archers. Yet, Infantary with their shields and pikes can just stand their ground and skewer any suicidal cavalry that charge them.
And yes, this was based on a real world relationship, there are lots of those relationships in the real world, for the navy for example submarines can kill most ships easily, thus the navies invented anti-submarine ships that unfortunately are fragile against normal ships, thus creating the relationship: submarine beats battleships, battleships beat frigates, and frigates beat submarines.
In World War II near the end, several navies realized that a good strategy was make some expensive battleships, that could kill anything but submarines, and then make loads and loads of frigates using civilian shipyards, and leave those to protect the battleships from submarines, and use submarines to attempt to kill unprotected battleships... Thus the balance of your numbers (battleships, frigates and submarines) proved to be important, too much of one type or another and you could have a problem in your hands (example, too much battleships, and submarines would easily wipe you out, too much frigates, and battleships could wipe you out, too many submarines and they were useless against enemies with a solid frigate squad)
|
|
|
|
|
64
|
Developer / Design / Re: player attributes, too less?
|
on: February 03, 2014, 11:06:29 AM
|
What do you people think about the number of attributes a player should have? Lets say, we are making a platformer game and every character has the following major attributes.
-attack -defense -speed
are they too less? what if we add some more attributes like: -power ups -health -jumping
if so then how can we balance out everything?
You should really explain what your game is about first... For example, what if our game is a quiz game where the winner is the one with highest amount of correct answers? Then those attributes are 100% irrelevant. What if your character can fly, then why the jump attribute? Or... if it is a fish? Or if your game actually is a Mario clone, then why the hell it has attack attribute?
|
|
|
|
|
66
|
Community / DevLogs / Nameless Ship Shooting Game
|
on: January 31, 2014, 11:14:56 AM
|
I am making a shoot em up, also known in portuguese as "jogo de navinha" that means "game of little ship". I started some time ago, but there is no interesting screenshot to show yet... But the basics are simple, it is a horizontal scrolling game (to fit those modern horizontal widescreens), and it will use only direction buttons plus a button to fire. I was reading a article on Gamasutra other day, and someone commented that someone else said (I think it was Will Wright, or Peter Molynoux, I don't remember) that if a button exists, the player must have a reason to NOT press it. And I remembered that several shooter games I've been playing, you just hold the fire button... Some even reasonably offer a auto-fire button. So I thought of making a game where firing is needed, but NOT firing is needed too. So far the rules is that when firing you move very slowly, so you must aim at the enemies, shoot, stop shooting, aim at the next enemy, the idea is to be very different than bullet hell genre where you just hold the fire button and dodge around and you hit enemies mostly by accident, the idea here is that you NEED to look where the enemy is, go to it, and THEN shoot it, and THEN stop shooting at it after it is dead. More aiming, less dodging. The score system will support that, the faster you are to move around the battlefield without neglecting things, the more score you will get. (probably I will use collectible items, ie: so instead of just hunting you also must move around getting your score). Yesterday I started researching what data structures I will use in the game (I am coding it in C), I will run some benchmarks, make a blog post, and paste the link here  Also I would like to note that this is a personal project, do not confuse it with Kidoteca (my company, where you can see our flagship game devlog in other thread).
|
|
|
|
|
71
|
Developer / Art / Re: We are designing a new main character, what you think?
|
on: January 23, 2014, 11:56:52 AM
|
Heh, for mischievous look we had this version, made by a artist that was with us only for the first two months of the company (actually this was the very first drawing of our character).  The CEO banned it though, he thought it was TOO mischievous, and he do not wanted to create another "Woody Woodpecker" character, he wanted to create a more curious one, but that are more careful toward the good side, no pranks, no cruel actions, and so on. (in fact we plan to have the character make a upset animation if you attempt to use dangerous objects on living beings, like use the machete on the monkey). I preferred that one, instead of the circle-head one, but we cannot have everything we want  We think we might reuse the concept in future games though, in other genres (ie: a action platformer for 10 year old kids for example might be more fitting for a mischievous and agile character).
|
|
|
|
|
72
|
Community / DevLogs / Re: How to Be a Tree
|
on: January 23, 2014, 10:54:23 AM
|
I freaking love this, amazing physics!  my only crit is that the dialogue is unnecessary and ruining the joke imo. I think it is the EXACT opposite, the dialogue makes the joke funny. I would not think the game was funny at all, just weird, if it had no dialogue.
|
|
|
|
|
73
|
Community / DevLogs / Re: sooth - minimal point'n'touch
|
on: January 23, 2014, 06:56:51 AM
|
Taking a look at this again, since it is the same genre as my main project. It is looking very sweet, I also liked the musician ideas. Really cool =D Lets make this genre flourish again ^.^ (well, although with recent Tim Schafer and Telltales help that is not really hard  )
|
|
|
|
|
77
|
Developer / Business / Re: How much did YOUR game sell?
|
on: January 23, 2014, 05:25:06 AM
|
|
I am looking at the last closed books of my company (this is from December 31 of last year, January is not counted in yet).
Discounting some stuff that I am contractually forbidden of disclosing (ie: OEM deals, some specific stores deals, and that sort of stuff) we had about 8000 sales so far.
We started developing stuff in March of 2012, and selling stuff in November of 2012. (our first demo was released in October 2012).
The sales might sound good... but they aren't, we are not a one-man shop (there are 3 fixed workers + some investors + some freelancers that we hire regularly and frequently).
EDIT: I forgot the interns, poor interns... We have right now eight of them.
|
|
|
|
|
78
|
Developer / Technical / Re: Developer Tools (WIP)
|
on: January 23, 2014, 04:54:35 AM
|
|
Where is Sublime Text on that list? That program is pure awesome, I am using it now to do most of my coding, and if I was its main dev there would be few things that I think that could be done to improve it, it is so near perfect that I fear that trying to improve more might wrap around and end making it suck.
|
|
|
|
|
79
|
Developer / Technical / Re: How I handle bullets in a shmup in C?
|
on: January 23, 2014, 04:52:49 AM
|
I found it quite nice to combine the "cleanup" step here with broad phase collision. A nice way to handle 2d collision is to just sort along one axis and then use that to only collide against relevant subranges. Anyway you can combine that sorting with the removal of "dead" projectiles/objects by essentially making dead or out of bounds objects always compare larger (that way they get automatically moved to the back of the array). This is also one of the use cases where using insertion sort is actually preferable over say quicksort since over a single timestep the ordering of stuff changes only locally most likely (temporal coherence in motion...) and insertion sort has about linear running time for almost sorted data.
I kinda like this use case as a nice example of a simple algorithm (insertion sort) gives you linear time complexity (both for sorting and broad phase collision) while being very cache friendly at the same time.
I did not understood much of what you said, my theoretical CS-fu has been weak lately, but sounds good, I will do some research =D Thanks!
|
|
|
|
|