[background=transparent]So I'm coding a survival rpg (uh, seriously? pretty original...). Well, at the beginning I didn't know of the survival element, only pretty focused on the rpg thing. But then I started to think to the story (I always need one), and it comes out a plot with you being tossed in this island, sentenced to exile for a crime you did not commit. Ok, but why an exile and not a simple death sentence? Because you are not a simple man. You are the prince, denounced by another (evil) member of the royal family. For jealousy, maybe (Moorcock?). So, you are a prince, and therefore you received a good education, can use a sword and so on. Maybe magical powers too. But you have none. No weapons, no food, no water, no dresses. The exile sentence is a royal-member-acceptable death sentence. By starvation... whence the survival element. I think that in the later game you will left the island to take your revenge, but that's completely another story.[/background][/font][/color]
[background=transparent]I (as you, I suppose) started and never finished a lot of projects. This is not the point, because every time I learned something new and improved my skills as a developer. Probabily this will never be a complete game too, I'm ok with that. I only want to try, and put things in order to go as far as I can.[/background][/font][/color]
[background=transparent]With this in mind, I produced a very simple design document, a thing I always do. Usually I start a new google doc, put everything comes to my mind on the sheet (like a brainstorm) and end with a checklist of features and rules. Then, I procede defining (and hopefully making) small prototypes, adding a couple of major features at time.[/background][/font][/color]
[background=transparent]The first prototype, named A (I'm original, just said...), will include:[/background][/font][/color]
[background=transparent]map exploration (island surface, no caves)[/background]
first bunch of life stats (hunger, thirst, stamina, the kind of survival things) that decrease according to the type of terrain I'm moving on
death and game over
[color=rgb(0,0,0)][font=Arial][background=transparent][background=transparent]I'm close to finish this first prototype, and here's a screenshot in its full programmer art glory:[/background][/background][/font][/color] [color=rgb(0,0,0)][font=Arial][background=transparent][background=transparent][/background][/background][/font][/color]
[background=transparent]I'm using SFML (C++) and Tiled for the maps. Graphical-roguelike visual style, turn based. Long life to RPGs![/background][/font][/color]
I've done a lot of experiments in the last months. Tried a couple of prototypes for a 2d rpg in sfml, sketched some game design ideas, studied a bit of directx11 in opposition to my old love, opengl. Tried to learn something more in the shaders universe. Or just to understand a bit of them.
I did not put anything of this in the journal, don't like to announce any vaporware thing passing through my mind.
But I also realized that I was lurking a lot on the other's journals, and that my last entry was more than two months ago! So I decided to share what I'm doing right now. Just for the pleasure of sharing itself.
Since I realized how I prefer opengl syntax over directx one, I switched back to it. I'm creating a scene using modern opengl, core profile, shaders and all the stuff. I think this is the fourth or fifth iteration in this process (maybe more), but the good thing is that this time I have a really light codebase for loading/rendering and it seems I understood something.
Since I'm in love with rpgs, my scene is very fantasy-oriented. A cave. An hypothetical first map for an hypothetical game, in which you have to escape from a cell and find your way out through the small cave. All of this trying to achieve a low poly, flat shaded style. I think it needs some more stalactites and pillars and details.
I'm also loving the process of thinking in terms of game design (modeling the map thinking at players movements, actions and fun, putting a feature only if it's needed for the (hypothetical ) gameplay: a little challenge here, something to find over there, and so on).
Oh, I also grabbed Blender again and tried to model something. Models in the screenshot are mine.
I thought for a bit to a method to render tiled maps (terrains) in a way that seems less... well, less tiled actually.
First idea was to have smaller tiles and different images for each terrain type: so instead of having one grass image for grass terrain, have a dozen of grass images (with little color differences) and then pick a random one each time.
I liked the idea and second thought was: I will end with a lot of tiles... how to handle them? If before I had 24x24 tiles, now I have 9 8x8 tiles for each original 24x24. There are a lot of tiles to cycle in when rendering. More over, I don't want to manually fill a map with all those things.
Next thought was the need to merge between different terrains. This is something I always struggle with, since I'm not an artist and can't produce decents transition tiles. But if I reduce a tile to a grid of tiles (the 9 8x8 tiles said before) I can look for nearby terrain type and use some piece of other terrains instead of the current one. For example, if I have a grass tile under a water tile I can render one of the first row grass subtiles with a water one.
The only problem remains the prolification of tiles (x9, actually). I experimented that the render loop suffers a lot with something like this:for(int r=0; r and I don't feel to complain the poor cpu for this.
So the only solution seemed to be prerender chunks of map into bigger textures, and the use them in the loop.
So I did it.
First I edited a really simple map with tiled (40x40 tiles), that could be a single area for a bigger world map. I used 3 terrains: swamp, dirt and grass. This is the result as exported image (and this is also like all my precedent project's maps looked like):
A swampy area with a kind of a road and some grass.
Then I coded something that parse the tmx (well, I already had from prev projects), pick every tile and build a texture with the same map using 8x8 tiles instead of 24x24 (using a second atlas with 8 terrains for each terrain).
Result is this:
A little more interesting, but still no transitions. Look at the road, so straight! Last, I applyed the auto transition method, and the result is this:
I'm pretty happy with it, even if I chose terrible colors
So, prototype has been done and I received a few favorable comments about it, now it's time to decide what to do next, and I decided I want to make a game out of it. A real game, with a decent level of polish, if possible.
I ran the prototype and made a list of all the things I would like to change in order to release a 0.1 version:
Major refactor: nothing user can see, but latest iterations of the prototype have made the code a mess!
Original art: I always thought that players deserve to find original art in a game. Games with ripped graphics are like songs made out of samples from other songs. Age of Rogues will born with original programmer art.
Better look for dialogs: seriously, they need...
Use of mouse: this implies the use of buttons and icons, not only keyboard shortcuts (that will remain)
Actual maps generators: at the moment world map is an empty grassy plain, areas are grass with trees tossed here and there, and dungeons are the same but with rocks. I want at least a world map with consistent mountains, hills and forests, and an area map that reflects the real world's tile terrain. Generators are a thing that I will improve at every release, but I really need to start somewhere.
Monsters in dungeons.
Obelisks in dungeons.
Background music. A single track of original music (I am a sort of musician, luckily).
At least, these are the elements that make me think at a game.
I'm spending a bit of time making the art (and finding a consistent style), but with gameplay and contents already made I don't have the usual bad feeling of being wasting time. I opted for a cuboid-pixel art, keeping the same palette of the free tileset I used.
Below is how the "choose your character" screen looks like at the moment (yes, clouds are moving). Bye!
Prototype of this game is finished, and this is yet a very great success for me.
As last feature I introduced dungeons (not really a roguelike without them ). Dungeons are not the ultra-deep things seen in other roguelikes: they serve the sole purpose to hide once more obelisks, giving the (design-) chance to put the most advanced ones in really dangerous places.
At the moment, dungeons are implemented as a submap of an area. There's one level only, and the entrance is the exit too (you go there not to find the exit, but obelisks, and you know where to go to back to the area map). I didn't spent a single minute in implementing an algorithm for their generation: they follow the same rules used for external areas, but with dirty terrain as default and rocks as barriers. I just wanted something to enter in, wander around, grab things and exit.
A feature of dungeons is that they use the character's dark-field-of-view stat in order to uncover explored tiles (instead of the field-of-view stat for the area map). This stat starts at 0: that means that you can't see anything around you if you enter a dungeon at the beginning of the game. You need to be equipped with torches, and you get torches as soon as you find the Fire obelisk (which must be placed NOT in dungeons...).
So, this part of this adventure has come to an end, and I'm pretty proud of what I have done. Now I want to play a bit with this toy and maybe polish a minimum to have something to release. With an early alpha (or late-prototype) I can think to run a page on indiedb and start an actual development.
But not now. Now I need an holiday.
EDIT: I put here the prototype exe as it is, for those interested in. "As it is" means that it lacks almost every kind of "user friendly" feature. A lot of things are there for the sake of test only: for example, dungeon entries are always in the first column of tiles, at (x=0, y=25) to make entry test easy. Enough apologies, enjoy!
Another update, with several improvements, new contents and a couple of things with heavy impact on gameplay. Let's proceed with order:
Content milestone reached The prototype's goal for content creation was to have 3 social obelisks (in order to complete a collection) and a Scientific one. I added Social Organization: Tribe (social obelisk) and Agriculture (scientific). With Fire and Stone Tools of the previous entry I can say I reached the goal, but this is not the only one...
Tribe gives me the opportunity to add a character to the options of the player, the Chieftain (the Tribe obelisks actually unlocks the Chieftain). So I had to code the lock/unlock system for evolute characters. You can see all characters in the list from the beginning, but can choose only the unlocked. A picture:
With the Chieftain I reached the second goal: to have three playable characters, one of which locked at the beginning. Chieftain has the power of found new villages, and is pretty good at fight. He has also a wider field of view, which is getting a lot of importance in this "release" because of a major change in the mechanics, which is next point.
Gameplay mechanics changed Exploration: when in world map, you can move only starting from an explored tile (area). Before, an area was setted "explored" simply going into the first time. Now this is not enough. You have to actually explore a certain amount of tiles before area is considered explored (61% at the moment). A tile in the area map is considered explored when reached by your field of view. Logical consequence is that the wider the field of view of the character, the better.
Cost of new characters: It's clear that you need more than a character to actually explore an area. You need at first harvesters because of their power of gather plants and thus food. But they're weak, and map is filled with beasts, so they die quickly. You then pick hunters to clear a bit the area, and finish with harvesters again to pick all the food (and obelisks if any!). I found this fun, but a bit ripetitive because of the absence of a real challenge. So I thought: what if every new character born with a cost? You have to keep more attention to your character's life. Cost is not per character (which can seems logic: high cost for evolute characters). Instead, it simply grows after every new character. It starts from 0 and increase of X every time a new character born. See again the picture above: here I was using X=10, so that was the 14th character. First time I played with this new mechanic I lost (gameover!), because I started to loose villages for starvation.
To end with, not a real mechanic but an improvement: persistance of area map data. It's lack was quite a bug, or a not yet implemented feature, but now it's there and works as expected. Characters shares explorations and area maps are not regenerated every time you enter in, which brings at situations in which you can have the most of them uncovered, like in the picture below.
I left only one big feature before I can consider the prototype finished: dungeons!
It took me almost a week to put together 8 hours of coding, but I ended up with the core mechanic done: obelisks!
While coding obelisks, I had in my mind Sean Bean's Boromir whispering "one does not simply hardcode a feature like obelisks!"... he was right. Obelisks and their discover change almost every game stat, starting from the various characters ones. I coded only two of the four intended for the prototype, but soon I realized that I simply cannot hardcode their impact on the world. I need something structured, with a minimal level of architecture.
So I did it. Obelisks data is stored in the form of list of structs and I have a couple of static functions that handle them and modify the world. Game only know about their code, keeping a [font='courier new']vector[/font] of the founded obelisks codes, and some switches do the rest.
I had to manage some new art. Even if I chose to use non-original tilesets, I had to browse a bit to find something suitable, and I ended up modifying something and creating some other images. All these things took some time to get done.
Two obelisks implemented so far: Stone Tools (on the Scientific [green] area) and Fire (on the Social [blue] area). Everytime you find an obelisk in the map (and bump into) a dialog shows a brief description of the technology and a list of game benefits, as you can see in the picture below:
A critical design point Finding obelisks expand your chances to win the game in many ways: Stone Tools, for example, gives a chance to Hunters to start kill something, so that Hunter becomes an interesting character. Obelisks are grouped by the maximum distance from the village they can be found. This is a critical design point. Stone Tools is meant to be found at 1 tile from a village, so that harvesters can find it, given that it is a basic tech you absolutely need. Rarest techs will be far from villages or deep into dungeons, and only advanced characters can reach them. MaxDistanceFromVillage is one of the Obelisk struct member, and one of the most important. Probably here is where the whole design will take place.
When an obelisks is found, all obelisks of the same type are removed from the map, and one of the circles on the corner is filled with the icon of the tech, as you can see below.
I started to actually play the game and, well, it is quite fun even with the great number of obelisks in each area. They will be a lot more rare in the game!
Some updates here: you can now grab things from the ground. Currently, you can grab mushrooms (if you have the ability "gather plants") and pieces of meat (if you have the ability "hunt for meat" and you manage to kill something, which is a big if). Grabbing food increases the food counter, of course.
Along with this, I fixed some bugs of minor importance and implemented a basic field of view. Since it is basically an exploration game, I think a proper field of view is mandatory. You cannot simply see all the map that can fit in the window. You have to move around and explore, with dangerous things hidden close to you.
In the real game this would be a good bresenham implementation, but for the sake of the prototype it is a simple "show every tile within a range of x tiles from me". Even so, it adds a lot to the gameplay! You have to explore almost the entire map to search for those obelisks (which do not exist at the moment...)!
Oh... I also managed the multi-village. Before there was only one village in the world, and every character born in that place. Now world is generated with some villages, and everytime a character born a village is picked. This bring to situations in which characters start to share world tiles they explored, like in the picture below, in which a new character is born in the village to the north and can see the piece of map discovered by its predecessor. World map tiles follow this rule, area map tiles don't.
The real game will be about uncover the world map generation after generation, with advanced classes that can move far away from the village of born. This thing of the range of movement brings a lot to the gameplay: for example harvesters can move 1 world tile from the village, while hunters can move 2. Hunters are stronger and tougher than harvesters, so it seems a good idea to choose them at the start of the game. But soon you understand that are they are not strong enough for the beasts out there, and they cannot grab mushrooms, so global food quickly decreases, and world loose villages. You'd better choose harvesters to (carefully) explore nearby areas, collect food from plants and hope to find first obelisks to upgrade your units. This put also some rules for the map generator when it comes to disseminate obelisks, and it is beauty to see that every aspect seems to be connected.
This is the first time I prototype something instead of starting writing the actual game (and fail). Good experience so far.
I could name this entry "Monsters & Items" and stop writing. But I will not. I like to explain. I found that keep these records is a really useful mental help, since it gives me close milestones and act as a sort of progressive brainstorming. Cool.
Stats & Skills
Implemented factories methods to create instances of monsters and items (food at the moment) to put on map. This is where character abilities come to an actual use. Character struct has gained some new attributes too, like an array of skills and stats values. I forced myself to keep this simple, putting only what is needed at the moment. Since I have monsters now, I have to manage their AI and a kind of combat system, and therefore I'm in need of, at least, hitpoints and attack/defense/damage values. These have become my character's stats. As for the skills, I made the same. I have two character classes: one that is able to recognise and grab plants, and one that is able to fight things and obtain meat to eat. I don't want to bind these skills to the classname (if you are an "harvester" you can grab plants), so I translate that into a skill system (if you have the skill "gather plants", you can do it). These lead to a more flexible design, in which advanced classes can do more than one special action, and (better) I don't have to hardcode things. In effect, I'm trying to put all in a data-driven way as soon as possible.
Living monsters: AI and combat system
As said, I implemented a basic AI for monsters too. They stay at their position until you enter in a certain range. At this point they start to chase you. If you go far enough from them they stop chasing. Obviusly, if they come to bump into you, they attack. You can attack also. I have implemented the melee combat system too. Nothing fancy: everyone has an attack and a defense value. For every point of attack a d6 is rolled and the sum is made. Same for defense value of the defender. If attack > defense, attacker hits and fixed damage is done. This way I don't have a fixed random range with some bonus, like in the d20 system, and I feel I can change things later. Again, at this point also I had to remember myself that I was working at the prototype: stop thinking at putting a visual effect for wounds, please. I plotted in the bottom status bar character's stats: you can see your hitpoints decreasing over there.
This bring to the fact that there's also another way to die, obviusly . So up to now you can die for starvation and wounds.
If you kill something and you have the right skill, that thing become a piece of meat in the map. You can't grab things yet, but this will be matter for tomorrow.
Here you are the Hunter and have killed a snake, that has become a piece of meat.
Map is filled with mushrooms too, but are strange things at you eyes,
and you don't want to have nothing to do with them.
Stats are oversized to let me test that snake is killable... initial hunter's stat are not that powerful!
Focus of this session of work was to define the gameover condition and manage the death and reborn of the character. Mission accomplished, even if in a very rough state.
There are two ways for die: one needed, which doesn't end the game, and one to avoid, as it's the real, classic, game over: you lost.
The good way is when your current character dies. It can (and must) happens for a lot of reasons: at the moment the only one is the lack of food. There's a good reason for this, which I'll explain soon. When you die the good way, you reborn in another area of the world map (currently in another village) and you can choose which class your character will play (see screenshot below)
The bad way to die has to do with the concept of the world being your real character: so when the world dies? In gameplay terms, it dies when humanity reaches extinction. Every roguelike/rpg has the concept of hitpoints: when they drop to 0 you die. Well, hitpoints in this case are the number of villages (human outposts) out there. At 0 humanity has to be considered extinguished. When this happens there's nothing more to do: game over.
Food is not the micromanagement thing that affects many roguelikes. I was simply in need of a consumable resource to give both the feel of time passing and the possibility for the world to loose a village. So, if villages are the hitpoints of the world, the consumable resources are the hitpoints of villages. When they drop under a certain amount the current character's village dies (and character too)
and you are a step closer to the end. Not only, consumable resources give me the opportunity to have to accumulate something, which is a very good (fun) game mechanic, imho. It gives a nerdy satisfaction to see that number growing .
Every epoch will have its consumable resource, it will not always be food: in a most advanced society this could be gold (money), or energy. A financial/economic crisis will be a real disaster in an evolute society.
Next screenshot shows these aspects: you have two indicators on the high status bar, with the consumable (food in stone age) and the villages.
Lastly, here is a screenshot of the tragic moment in which you are so close to your death for starvation (unfortunately for you, world generator puts no food on map at the moment, so...):
No fighting classes can become really useful if they give the opportunity to increase the consumable resources, and going in the wilderness (which must be really dangerous) with a poor harvester can be deadly fun .
Now that I have the game beating you, I can start working on how to survive in such hostile place.
At the end of 8 more hours of coding I've got the following:
gui system started
transition between world and area map
minimal area map generator
movement in the wilderness
And a couple of screenshots:
In the first one you can see the world map with the addition of some gui elements: the 4 techs/obelisks groups and a toolbar. Toolbar shows the list of commands available for the current character in the current world tile. For the prototype, I opted for a simple text, but in the real game this will be a suite of icons (reachable by keyboard shortcut or mouse click).
You will notice that some tiles are visible even if heavily shaded: I decided to let the player view the unexplored tiles once he/it/she (damn english! ) visit them (simply going on). I think it can add a strategic clue. Once explored, they will become bright as the village.
In the second you have the result of the "E" key pressed on a world tile: explore mode! World map change to Area map and you play as a traditional roguelike: you have your sprite (according to the character class) and you go through the wilderness searching for things (obelisks, but also food and other resources) and fighting beasts. None of this implemented yet.
About the refactor
It sounds silly to have done a refactor after only one day of develop: well, it is, perhaps. But I noticed I was starting to have some classes (the world and area generators, for example) with no data at all and static methods only. I got rid of these classes for simple functions. Less files, less allocations. I'm not coding in java, after all
So project has started . First I setted a working environment, with all the linkage and the bitbucket repo working, and an empty-black-screen exe, then I started some actual coding. Where to start? I decided to go with the world map, with the goal of having something to put on screen. So, after a bit of hours I have a Tilemap class filled with tiles by a (pretty dummy at the moment) world map generation routine (together with some utility classes to load and serve pieces of texture from the tilesheet file, to reference count my objects and do some basic math I needed).
Map is showed centered at the character's village position, which is the only tile setted as "visited". The renderer routine ignores the unvisited tiles: in a prototype this is ok, but in the real game I suppose I'll have to put something on screen rather than the empty black. Anyway, this, with a Character class to put the character's sprite on map, is what you can see in the beautiful screenshot below .
Remember that this is the world map, not the Area map, so I chose a neutral sprite for the character: a simple human face, suitable for all the character's classes. In the Area map you will see the real character's sprite, according to its class. You will notice that character is one tile away from the village, actually in an "unvisited" world area. This is because I had the world movement implemented yet, with the following rules:
You can start moving only from a visited tile;
You can get away from your home village for a maximum number of tiles (range) given by your class;
And, obviusly, you cannot go out of the world bounds
I want to have characters class to be data-driven: in the real game data will be read from a file, here I simply hardcoded some values in a couple instances of the CharacterDescriptor struct. This, together with a kind of Factory, give me the two kind of available characters to play with. I played with them a bit, testing the range movement, adding visited tiles to see what happens, imaging the game is finished.
Yesterday I had a very nice (and productive) ideas exchange with some of you gdnetters, which can be seen here. It was about an idea for a pretty unusual roguelike. Don't want to rewrite all the brainstorming here, only to start a dev diary for a prototype of the game.
Day 0 is about some sketches and the choice of the wip title. After a couple of ideas, I chose Age of Rogues, since the name contains the two identified keywords of the game: Age (since it is all about world ages and humanity progression) and Rogue (obviously, been a roguelike kind of game). A quick search on indiedb and google give me no results, so here we are.
I sketched down a couple of "screenshots", to give me an idea of what need to be putted on screen, and why. This will change almost for sure, but I need to start from somewhere.
World Map view
Full game will have a dozen of technologies to be discovered in order to pass to the next Age, grouped into 4 types: Social, Scientific, Artistic and Spiritual. This will be the main goal of the game, so I like player can have this situation always under his eyes, hence the four screen corner covered with relative tech icons: they will show in fullcolor the discovered techs, and in black-white or the like the undiscovered ones.
Here each tile is a macro-tile: for example your native village will be the starting tile. You will see a fog of war on the not yet visited tiles. In order to visit a tile you need to step in and enter the area. This will bring to the Area Map view, which is where the roguelike part of the game take place.
Area Map view
This is almost equal to the World Map view, but all the stats refer to the character instead of the world. Here you will explore the area, searching for obelisks, fighting things etc. etc.
I also chose the tools (c++ and sfml), set the prototype's goals (Age of Stone, with the implementation of the social techs and one of the scientific ones only, with 2 base classes for the characters and 1 unlockable class), and chose the free art (don't like to use standard free spritesheets/tilesets, but for a prototype I think it's better to not expect art to myself, considering I'm not an artist too).
I will not put a lot of effort on the procedural things, like the world/area/dungeon generation: just something to fill structures and have a playable map to test features.
With these restrictions I hope to have a playable prototype in about 7 days of develop. Wish me good luck!
Things are going quickly, and after a few days from 0.1, I completed the checklist for 0.2. Woah!
The main feature was the ability of the engine to create monsters, put them in map and allow player to slay them in melee. A spawn system was also desired. A single monster to begin with: goblin, obviously. Oh, and the time system went on also (rounds count).
Secondary features were simply more items to play with and the ability of the engine to prevent player to use an item if its character class doesn't allows... i.e. no swords or armors for magic-users.
About Spawns Every Area (the 64x64 tiles piece of world in which player currently is) has an array of Spawn things. A Spawn is a sort of timer programmed to create and put in map a monster of a kind every X rounds at a certain position. After N creatures spawned it is destroyed. Viewed in these terms, is a very slow paced particle emitter For example, a pile of garbage can be a spawn point for dire rats or centipedes or other kind of vermins, or a cemetery for zombies. I think this way the Area is more alive, and player doesn't ever know if it's all been cleared or not.
Next version will give some kind of basic AI to goblin and maybe a couple or more of new monsters. I would like to manage the loot also.
Here is a screenshot of a cleric beating a goblin.
So, after some prototypes and some adventures in the isometric universe, I took a step back to good old ascii roguelike. I also switched from C++ to good old ansi C. I kept SFML, in its C flavor, CSFML.
Why C? I love C++, but simply it seems I can't get a whole game out of it... I always end wasting time in over-engineered solutions, and the last kid in town, Entity-Component paradigm, has done its part. Sometime less is better. It was better for me, at least. I discovered you can also live well without classes, templates, inheritance, polymorphism and all the OOP stuff. The more, I discovered I am more productive. So here I am.
The RedBox Engine So, what is this RedBox Engine? I am making the core mechanics of a system capable of running a D&D RedBox adventure module. The actual game will be data driven, with a bunch of files to give in input to the executable. In this first release (which is not a release at all, but only a video), I reached my goals:
have a procedurally generated character (choosed random between the classic ones: fighter, thief, magic-user, cleric, elf, dwarf and halfling)
load a world made of one area
have a procedurally generated forest to walk in, with some items on the ground
have the player be able to walk around, look, pick up items, drop'em and equip'em
Character name is also randomized, and every class has its own name generator (so I have fighters names, clerics names and so on). Emphasis has been placed on a clear interface, in which player can visualize all the important stuff in the main window. So character sheet, equipped items, messages and the list of commands (something that many roguelike creators tend to consider less important) are all in the main screen with the game field and the area display.
Ok, but the game? There's no a game yet. I am reading some old Dragon magazine to find a suitable one, but the very first game will probably be the solo adventure in the Player's Handbook (the one in Bargle's lair with goblins and skeletons, do you remember?).
The big picture It will be great if I could load a game module, play it with my character, survive 'till the end, export the character and import in another module. It will be great if a module editor could be used to create and edit the files needed. Maybe in a community of creators. With online character's sheets. With...
So I'm working on this sort of roguelike of mine. It will not be a dungeon-only roguelike, I also want wilderness, and cities, villages and so on... something like ADOM, but procedural (ADOM world map is static).
So first step is to generate some kind of overworld. I ended up with using a particle deposition strategy, and these are a couple of results I obtained so far:
Water is a side-effect at the moment, I have to realize if I want it or not, and if yes I'd probably go with some better way to achieve it.
First in-game screenshot for my RPG work, no mockup this time. I'm no longer scared by isometric draw!
It's all going quite well. Tiled is, as always, THE tool for maps, together with the simple tmx loader I wrote. The screenshot shows also the player character (a human male, but there's also the female flavour and the high-elf and silvan elf, male and female too). I plan to make "dynamic" dressing, but I have not developed any kind of equipment system, hence the character is almost naked.
Another think that's going the right way is the entity-component-system paradigm. I must say I like it. Write components is easy, and write systems is funny, for the moment. Not sure it's really orthodox, but I added a TurnOn/TurnOff switch to the Systems in order to choose what must run and what not. For example, during the character creation I have a DrawCharacterSystem that draws the character sprite in the portrait's space: this is no longer wanted during actual gameplay.
Next step will be add some kind of movement. I opted for a point and click movement type (so with A* for pathfinding), like in Baldur's Gate series. This way character will not be the center of the scene: player will have to move mouse near the bounds of the screen in order to scroll the map. This is also working yet.
Last entry was about some ramblings about a possible RPG, something easy enough to be developed by me myself alone, with regard to my poor artistic skills.
It ended up with a mock of some faces in a almost-top-down view. As mentioned in the post, a night of sleep changed my vision (as often).
I never really experimented with isometric views, so I said: why not? Google, isometric art tutorial, some sketch, some try in Tiled and now I've got another mock with poor (but, again, consistent) art that I want to share here.
I think it looks quite better than the previous one, more immersive... or not?
Occasionally I fall in the need of design some kind of RPGish stuff, so here we are.
I cannot draw, or at least I can draw to the level of a 6 years old baby, which is my greatest limit, because I love to do my stuff alone. That said, I'd like to make a game with mechanics similar to Baldur's Gate. Not the graphics, only the mechanics, which is mainly the pause-based combat system and the 6 men party management.
Yeah, but how to do something like that with so limited draw skills (no animations, no human-like figures)? I also want to keep it simple enough to have at least a chance to go somewhere, if I start. I'm pretty expert in 2D top down games, but zero experience on isometric. I played a while with the insane idea of 3D, but luckily I finally discarded.
This mock shows my ideas, with the good guys on the left and the bad ones on the right. Top down, no animations, grid based movement for easy A*... I have now to sleep over it to understant if it can works or if it will brings to a boring and not satisfying game.
Maybe with a good story, some nice particle effects, a nice music, a well defined set of rules (who said d20?) and a lovely hand crafted world even a poor and basic (but consistent) graphic style can lead to ad immersive game experience.
No, really.... I'm making a game engine. Not a public engine that will be used by a large community, or something that can compete with all of the monsters out there like Unity3D. I'm making an engine for my own.
Why? First, I have no hurry to get a game complete and second, I'm quite more interested in learn how modern opengl works than making a playable game. Third, I think that I can't simply follow some tutorial and copy paste pieces of code in order to learn something. I have to refactor the whole thing, to think about connections between actors and calls. I have to write an engine. My engine.
And my engine has a name yet: IdraEngine (because it's always important pay attention to details, in inverse order of importance...)
Idra is the italian (like me) word for hydra, the mythological monster with a lot of heads. Like the engine, once completed.
[font='trebuchet ms']Solution structure [/font]
Up to now it is formed by a bunch of static lib c++ projects and an executable project to use as Demo, to test features. Major feature now is rendering a textured quad.
The rendering part is composed by two project: one with abstract class definitions and one with opengl implementation. Maybe one day I'll add a DX implementation, who knows. I like to have decoupled tiers and work with the abstract definition in real projects (well, the textured quad demo currently ).
For the OS layer (you know, window creation, context, input, timer...) I choosed GLFW but, again, I separated the abstract class from the implementation, so that I have a IEWindow and a IEWindowGlfw in another project. Maybe a IEWindowSdl or a IEWindowSfml will come later.
I choosed to get rid of them because, anyhow, I don't like use the "using" command. So, instead of write continuously ie::Window, I simply write IEWindow. Each class or struct has the IE prefix.
Each class or struct comes with two typedefs: IEPName for pointers, IECPName for const pointers.
Not so clear even in my mind, but I dream that, at the end, it will make me able to:
Load and render 3D scenes with fancy lighting effects
Manage basic physic (collisions and gravity)
Manage sound effects
Manage entities with the Entity-System-Component paradigm
Have a bunch of visual tools that generates app code for me, or at least the most boring parts
[font='trebuchet ms']The Test Project (aka, the Real Game, aka The Thing That Will Never Happens)[/font]
Well, I have a game project in my mind in fact, and I would like to bring it to the light using IdraEngine: a space shooter with first person view in which you are a fighter pilot and fight only with giga-sized bosses, with emphasis on maneuvers and ship's energy managing: something like Luke flying across the Death Star, with laser cannons to dodge and enemy fighters to break down and a few weaker points to shoot at.
Enough words for now. I will post here the progresses, of course, or the record of the failure. Something fun, in any case.
There's a new kid in town... so sang Eagles some years ago.
Hi all, I'm the new kid in town: C# programmer (mainly) in the day-paid-job, game dev wannabe in the free time, in love with C++.
This Journal will hold some ramblings about my free-time explorations. You know, something about games I'll never finish and attempts at putting together enough features to build an engine. The dream of us all, I guess.
At the moment I'm playing with modern OpenGL (3.3+), having fun with those shaders and vertex arrays and buffer objects & co. The short term dream, up to now, is to code an engine and build a 3d space shooter with it. The lifelong term dream is to code, obviusly, the Perfect RPG (tm).
I released a couple of flash games and a 0.2 version of a 3d roguelike called "Beltham's Lair" under the RedPill Games alias, which you can find here.